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

230 lines
10 KiB
C++
Raw Normal View History

2010-10-27 12:45:03 +01:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
re-base on ALv2 code. Includes (at least) relevant parts of: linecap: Reintegrating finished LineCap feature Patch contributed by Regina Henschel http://svn.apache.org/viewvc?view=revision&revision=1232507 Patches contributed by Sven Jacobi impress212: #i81610# fixed animation export http://svn.apache.org/viewvc?view=revision&revision=1167620 impress212: drawinglayer gbuild environment changes http://svn.apache.org/viewvc?view=revision&revision=1167627 http://svn.apache.org/viewvc?view=revision&revision=1167628 impress212: DffPropSet -> minor code improvements, removing table http://svn.apache.org/viewvc?view=revision&revision=1167634 impress212: #158494# fixed excel import (text rotation) http://svn.apache.org/viewvc?view=revision&revision=1167638 Patches contributed by Armin Le Grand Svg: Reintegrated Svg replacement from /branches/alg/svgreplavement http://svn.apache.org/viewvc?view=revision&revision=1220836 #118728# changed indentifying definitions for Svg file detection http://svn.apache.org/viewvc?view=revision&revision=1229961 #118838# LineGeometry creation for complicated cases optimized to create single Polygons http://svn.apache.org/viewvc?view=revision&revision=1236232 #119176# corrected file type detection for SVG for svg files without xml header http://svn.apache.org/viewvc?view=revision&revision=1309445 #118728# Extended Svg file detection http://svn.apache.org/viewvc?view=revision&revision=1230531 #118529# solve break converters and convert commands for OLEs and images http://svn.apache.org/viewvc?view=revision&revision=1186168 svg: added WaE changes from branch svgreplacement to trunc http://svn.apache.org/viewvc?view=revision&revision=1222974 svg: corrected missing member initialization http://svn.apache.org/viewvc?view=revision&revision=1226134 fix for #118525#: Using primitives for chart sub-geometry visualisation http://svn.apache.org/viewvc?view=revision&revision=1226879 #118898# Adapted ImpGraphic::ImplGetBitmap to correctly convert metafiles to bitmapEx ... http://svn.apache.org/viewvc?view=revision&revision=1293316 fix for #118525#: removed no longer used variable maOriginalMapMode, one more exception eliminated http://svn.apache.org/viewvc?view=revision&revision=1227097 #16758# Added buffering to the VDev usages of the VclProcessor2D derivates... http://svn.apache.org/viewvc?view=revision&revision=1229521 #116758# Secured VDev buffer device to Vcl deinit http://svn.apache.org/viewvc?view=revision&revision=1230574 #116758# added remembering allocated VDevs for VDevBuffer to be able to also delete these when vcl goes down; it should never happen, but You never know http://svn.apache.org/viewvc?view=revision&revision=1230927 #118730# Changed SvgClipPathNode to use MaskPrimitive2D for primitive representation instead of TransparencePrimitive2D http://svn.apache.org/viewvc?view=revision&revision=1231198 #118822# secured 3D geometry creation (slices) by subdividing the 2D source polyPolygon early http://svn.apache.org/viewvc?view=revision&revision=1234749 #118829# enhanced Svg gradient quality, obstacles avoided http://svn.apache.org/viewvc?view=revision&revision=1235361 #118834# Unified usage of TextBreakupHelper as single tooling class for i18n text primitive breakup http://svn.apache.org/viewvc?view=revision&revision=1236110 #118853# added square pixel size limit to conversion of TransparencePrimitive2D to Metafile action http://svn.apache.org/viewvc?view=revision&revision=1237656 #118824# coreccted mirroring and boundrect when the graphicmanager is used for bitmap output http://svn.apache.org/viewvc?view=revision&revision=1240097 #115092# Corrected VclProcessor2D::RenderPolygonStrokePrimitive2D for various optimization scenarios http://svn.apache.org/viewvc?view=revision&revision=1241434 #118783# Corrected errors in ID strings, corrected Svg line/fill export, corrected polygon close state http://svn.apache.org/viewvc?view=revision&revision=1232006 #118796# corrected null-pointer usage in SVG text exporter http://svn.apache.org/viewvc?view=revision&revision=1240262 #118729# Use GraphicStreamUrl and GraphicUrl to allow multi image import with linked graphics, too http://svn.apache.org/viewvc?view=revision&revision=1229962 #118898# corrected error in GDIMetaFile::GetBoundRect in handling MetaFloatTransparentAction http://svn.apache.org/viewvc?view=revision&revision=1293349 #118855# Corrected handling of possibly created empty clipRegions after PolyPolygon clipping http://svn.apache.org/viewvc?view=revision&revision=1237725 #115962# Better (but not yet optimal, see comments in task) handling of MetaFloatTransparentAction in PDF export http://svn.apache.org/viewvc?view=revision&revision=1241078 IP clearance: #118466# This patch removes librsvg, libcroco, libgsf, ... http://svn.apache.org/viewvc?view=revision&revision=1200879 118779# Added svg content streaming in/out to ImpGraphic stream operators http://svn.apache.org/viewvc?view=revision&revision=1231908 linecap: correctons for WaE and mac drawing http://svn.apache.org/viewvc?view=revision&revision=1232793 svg: uses current system Dpi for Svg replacement image creation http://svn.apache.org/viewvc?view=revision&revision=1233948 Patches contributed by Mathias Bauer (and others) gnumake4 work variously http://svn.apache.org/viewvc?view=revision&revision=1394326 http://svn.apache.org/viewvc?view=revision&revision=1396797 http://svn.apache.org/viewvc?view=revision&revision=1397315 http://svn.apache.org/viewvc?view=revision&revision=1394326 Remove duplicate header includes. cws mba34issues01: #i117720#: convert assertion into warning http://svn.apache.org/viewvc?view=revision&revision=1172352 118485 - Styles for OLEs are not saved. Submitted by Armin Le Grand. http://svn.apache.org/viewvc?view=revision&revision=1182166 cws mba34issues01: #i117714#: remove assertion http://svn.apache.org/viewvc?view=revision&revision=1172357 Patch contributed by Jurgen Schmidt add some additional checks to ensure proper reading operations http://svn.apache.org/viewvc?view=revision&revision=1209022 mostly prefer our stream / bounds checking work. Patches contributed by Herbert Duerr #i118816# add clarifying comment regarding Font::*Color*() methods http://svn.apache.org/viewvc?view=revision&revision=1233833 extend macro->string handling for empty strings http://svn.apache.org/viewvc?view=revision&revision=1175801 avoid magic constants for SALCOLOR_NONE http://svn.apache.org/viewvc?view=revision&revision=1177543 initialize slant properly in ImplFontMetricData constructor (author=iorsh) http://svn.apache.org/viewvc?view=revision&revision=1177551 #i118675# make check for extension updates more stable http://svn.apache.org/viewvc?view=revision&revision=1214797 #a118617# remove VBasicEventListener.dll binary There are no known users depending on its CLSID http://svn.apache.org/viewvc?view=revision&revision=1203697 Patches contributed by Ariel Constenla-Haile Fix build breaker on Linux/gcc http://svn.apache.org/viewvc?view=revision&revision=1221104 Fix crash when trying to instantiate css.graphic.GraphicRasterizer_RSVG http://svn.apache.org/viewvc?view=revision&revision=1215559 Patches contributed by Oliver-Rainer Wittmann sw34bf06: #i117962# - method <SwFlyFrm::IsPaint(..)> - consider instances of <SwFlyDrawObj> http://svn.apache.org/viewvc?view=revision&revision=1172120 sw34bf06: #i117783# - Writer's implementation of XPagePrintable - apply print settings to new printing routines http://svn.apache.org/viewvc?view=revision&revision=1172115 gnumake4 work variously from Hans-Joachim Lankenau http://svn.apache.org/viewvc?view=revision&revision=1397315 http://svn.apache.org/viewvc?view=revision&revision=1396797 http://svn.apache.org/viewvc?view=revision&revision=1396782 http://svn.apache.org/viewvc?view=revision&revision=1394707 plus some amount of re-splitting of legacy headers. Patch contributed by Pavel Janik WaE: Remove unused variables. http://svn.apache.org/viewvc?view=revision&revision=1230697 Patches contributed by Takashi Ono mingwport35: i#117795: MinGW port fix for vcl2gnumake http://svn.apache.org/viewvc?view=revision&revision=1172091 mingwport35: i#117795: MinGW port fix for vcl2gnumake http://svn.apache.org/viewvc?view=revision&revision=1172091 Patch contributed by Christian Lippka impress212: #i98044# re enable Text menu for outline and title shapes http://svn.apache.org/viewvc?view=revision&revision=1167639 Patch contributed by Andre Fischer 118674: Made category B code optional and disabled by default. http://svn.apache.org/viewvc?view=revision&revision=1215131 118881: Ignore empty paragraphs after bullets. http://svn.apache.org/viewvc?view=revision&revision=1296205 Patches contributed by Philipp Lohmann ooo340fixes: #i117780# use rtl allocator http://svn.apache.org/viewvc?view=revision&revision=1172087 ooo34gsl02: #i117807# fix an off by one error (index actually inside the pfb section header) http://svn.apache.org/viewvc?view=revision&revision=1167576 various cleanups, related compilation fixes, warning cleanups, re-working of obsolete stl template pieces to use boost instead, changed string classes, re-adapt KDE about data, about dialog, fixing warnings, and other fixes & improvements. Disable svg import / render for about/ branding code-paths for now. Restore full icon theme set. Remove OS/2 conditionals and sources. Remove conflicting gtk/full-screen monitors support. Retain existing svg rasterizer files - temporarily disabled. Standardize stringificaiton and fixup dllpostfix issues. Rename SvgGradientHelper::== to equalTo to avoid overloading issues. Use the flat GdiPlus API for LineCaps calls.
2012-10-09 12:22:23 +01:00
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following license notice:
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed
* with this work for additional information regarding copyright
* ownership. The ASF licenses this file to you under the Apache
* License, Version 2.0 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
#ifndef _EXTENSIONS_PROPCTRLR_BROWSERLISTBOX_HXX_
#define _EXTENSIONS_PROPCTRLR_BROWSERLISTBOX_HXX_
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
#include "browserline.hxx"
#include "modulepcr.hxx"
#include "pcrcommon.hxx"
#include <com/sun/star/inspection/XPropertyControl.hpp>
#include <com/sun/star/inspection/XPropertyHandler.hpp>
#include <vcl/scrbar.hxx>
#include <vcl/lstbox.hxx>
#include <vcl/button.hxx>
#include <tools/link.hxx>
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
#include <rtl/ref.hxx>
#include <set>
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
#include <vector>
#include <boost/unordered_map.hpp>
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
#include <boost/shared_ptr.hpp>
//............................................................................
namespace pcr
{
//............................................................................
class IPropertyLineListener;
class IPropertyControlObserver;
struct OLineDescriptor;
class InspectorHelpWindow;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
class PropertyControlContext_Impl;
//========================================================================
//= administrative structures for OBrowserListBox
//========================================================================
typedef ::boost::shared_ptr< OBrowserLine > BrowserLinePointer;
struct ListBoxLine
{
OUString aName;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
BrowserLinePointer pLine;
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyHandler >
xHandler;
ListBoxLine( const OUString& rName, BrowserLinePointer _pLine, const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyHandler >& _rxHandler )
: aName( rName ),
pLine( _pLine ),
xHandler( _rxHandler )
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
{
}
};
typedef ::std::vector< ListBoxLine > ListBoxLines;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
//========================================================================
//= IControlContext
//========================================================================
/** non-UNO version of XPropertyControlContext
*/
class SAL_NO_VTABLE IControlContext
{
public:
virtual void SAL_CALL focusGained( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& Control ) throw (::com::sun::star::uno::RuntimeException) = 0;
virtual void SAL_CALL valueChanged( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& Control ) throw (::com::sun::star::uno::RuntimeException) = 0;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
virtual void SAL_CALL activateNextControl( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& CurrentControl ) throw (::com::sun::star::uno::RuntimeException) = 0;
protected:
~IControlContext() {}
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
};
//========================================================================
//= OBrowserListBox
//========================================================================
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
class OBrowserListBox :public Control
,public IButtonClickListener
,public IControlContext
,public PcrClient
{
protected:
Window m_aLinesPlayground;
ScrollBar m_aVScroll;
::std::auto_ptr< InspectorHelpWindow >
m_pHelpWindow;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
ListBoxLines m_aLines;
IPropertyLineListener* m_pLineListener;
IPropertyControlObserver* m_pControlObserver;
long m_nYOffset;
long m_nCurrentPreferredHelpHeight;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >
m_xActiveControl;
sal_uInt16 m_nTheNameSize;
sal_uInt16 m_nRowHeight;
::std::set< sal_uInt16 > m_aOutOfDateLines;
sal_Bool m_bIsActive : 1;
sal_Bool m_bUpdate : 1;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
::rtl::Reference< PropertyControlContext_Impl >
m_pControlContextImpl;
protected:
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
void PositionLine( sal_uInt16 _nIndex );
void UpdatePosNSize();
void UpdatePlayGround();
void UpdateVScroll();
void ShowEntry(sal_uInt16 nPos);
void MoveThumbTo(sal_Int32 nNewThumbPos);
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
void Resize();
public:
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
OBrowserListBox( Window* pParent, WinBits nWinStyle = WB_DIALOGCONTROL );
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
~OBrowserListBox();
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
void UpdateAll();
void ActivateListBox( sal_Bool _bActive );
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
sal_uInt16 CalcVisibleLines();
void EnableUpdate();
void DisableUpdate();
bool Notify( NotifyEvent& _rNEvt );
CWS-TOOLING: integrate CWS dba32g 2009-09-09 07:53:55 +0200 oj r275964 : replace strlen with rtl_str_getLength 2009-09-07 20:59:10 +0200 fs r275913 : disable the CopyTableWizard test until issue 104869 is fixed 2009-09-07 12:17:31 +0200 oj r275885 : #i104810# remove de as lang 2009-09-05 22:26:21 +0200 fs r275857 : protect StateChanged against re-entrance 2009-09-05 22:25:52 +0200 fs r275856 : don't attempt to classify the parent of a form as control 2009-09-05 22:25:29 +0200 fs r275855 : protect against re-entrance 2009-09-05 00:11:40 +0200 fs r275835 : #i10000# 2009-09-04 23:25:50 +0200 fs r275834 : #i10000# 2009-09-04 23:23:47 +0200 fs r275833 : #i10000# 2009-09-04 21:49:37 +0200 fs r275830 : #i10000# correct wrong conflict resolution 2009-09-04 20:59:51 +0200 fs r275829 : CWS-TOOLING: rebase CWS dba32g to trunk@275801 (milestone: DEV300:m57) 2009-09-04 11:08:32 +0200 oj r275791 : #i104780# new version 1.2.0 2009-09-03 22:29:21 +0200 fs r275775 : OSL_TRACE doesn't need \n anymore 2009-09-03 08:33:21 +0200 fs r275743 : CWS-TOOLING: rebase CWS dba32g to trunk@275331 (milestone: DEV300:m56) 2009-09-02 13:48:12 +0200 fs r275708 : removed useless include 2009-09-02 13:45:43 +0200 fs r275707 : more since tags, which are used across offapi/udkapi 2009-09-02 13:23:04 +0200 fs r275705 : should *not* have the dtor, copy ctor, and assignment operator compiler-generated, else we run into trouble as soon as the compiler creates different versions of our singleton member's static data in different libraries 2009-09-02 12:32:45 +0200 fs r275704 : AutoIncrementIsPrimaryKey is a driver setting, not a data source setting 2009-09-02 11:42:49 +0200 fs r275701 : URL meta data are meta data which are valid for all connections of this type, not per-data-source properties. Settings them as data source properties is a hack. 2009-09-02 08:43:34 +0200 fs r275696 : 3.x.x is not a valid 'since' tag 2009-09-01 16:05:24 +0200 fs r275665 : #i104686# don't treat controls bound to read-only columns as required 2009-09-01 13:10:22 +0200 fs r275657 : #i104574# use PageUp/Down to scroll through the complete page 2009-09-01 07:04:48 +0200 oj r275641 : #i104104# correct line ends 2009-08-31 15:52:34 +0200 fs r275612 : #i104410# 2009-08-31 12:29:05 +0200 fs r275596 : #i104364# 2009-08-31 12:28:56 +0200 fs r275595 : #i104364# 2009-08-31 11:43:09 +0200 fs r275593 : #i104649# JavaDriverClassPath is also a known JDBC-bridge setting 2009-08-31 11:41:37 +0200 fs r275592 : #i104649# 2009-08-28 21:48:27 +0200 fs r275552 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI 2009-08-28 21:48:17 +0200 fs r275551 : #i96862# do not show the 'Create a new database' option when a) no embedded/dBase driver is installed or b) the configuration requests to hide the option 2009-08-28 21:47:19 +0200 fs r275550 : during #i96862#: renamed the configuration data which controls availability of certain DBA-related UI 2009-08-28 21:46:41 +0200 fs r275549 : #i96862# renamed and extended the configuration data which controls availability of certain DBA-related UI 2009-08-28 15:10:19 +0200 fs r275535 : #i96862# if no embedded driver is installed, use dBase for creating new DBs. If no dBase driver is installed, too, do not offer the 'Create new database' option 2009-08-28 14:03:04 +0200 fs r275532 : #i104454# allow multiple fields to display the same column 2009-08-28 13:14:00 +0200 fs r275528 : #i104584# driver meta data do not belong into a data source's settings 2009-08-28 13:09:57 +0200 fs r275527 : properly chech the MySQL type buttons (else next/back in the wizard leads to state with two buttons checked) 2009-08-28 13:09:17 +0200 fs r275526 : #i104584# driver meta data do not belong into a data source's settings 2009-08-28 13:07:18 +0200 fs r275525 : BooleanComparisonMode is a property, or a feature - but not a driver meta data 2009-08-28 11:00:31 +0200 fs r275521 : #i104580# 2009-08-28 10:40:05 +0200 fs r275519 : #i104577# correct assertion: If the template node type is ANY, then any value type is allowed 2009-08-28 10:09:30 +0200 fs r275518 : #i104575# implement Named Pipe UI 2009-08-28 10:09:07 +0200 fs r275517 : pass the trigger-event to IWindowOperator::operateOn / work with VclWindowEvents, not VclSimpleEvents 2009-08-27 14:27:36 +0200 fs r275484 : ImplPosTabPage: respect mbEmptyViewMargin for WINDOWALIGN_LEFT 2009-08-27 13:43:56 +0200 fs r275480 : merging latest changes from CWS dba32f herein 2009-08-27 13:23:07 +0200 fs r275475 : #i103882# 2009-08-27 11:56:55 +0200 fs r275466 : #i104544# SetState: Do not call Update at the window which we just set text for. It should (sic\!) not be needed, but causes trouble 2009-08-27 11:55:34 +0200 fs r275465 : #i104544# do not allow re-entrance for impl_ensureControl_nothrow Actually, this is part of the fix only. I also removed the code which triggered this re-entrance (from the grid control implementation), but to ensure it won't happen, again, I added some safety herein. 2009-08-27 10:14:11 +0200 fs r275459 : preparations for supporting a 'NamedPipe' parameter for the MySQL Connector/OOo 2009-08-27 10:13:21 +0200 fs r275458 : preparations for supporting a 'NamedPipe' setting for the MySQL Connector/OOo 2009-08-27 10:11:14 +0200 fs r275456 : outsourced the MySQLNative settings into a dedicated class, to not duplicate all the code in two tab page implementations 2009-08-26 14:18:13 +0200 fs r275422 : #i10000# 2009-08-26 13:26:36 +0200 fs r275419 : ignore output paths 2009-08-26 13:23:38 +0200 fs r275417 : support the LocalSocket property for the MySQL native driver 2009-08-26 13:17:05 +0200 fs r275416 : some re-factoring, to outsource the tab page for setting up the MySQLNative connection, into a dedicated class (needed later) 2009-08-26 13:15:15 +0200 fs r275415 : support a NoThousandSep property for NumericFormatters - I'm tired of correcting this at runtime, instead of controlling it in the resource 2009-08-26 11:45:08 +0200 fs r275410 : oops, 'flat' shouldn't have got lost 2009-08-26 09:38:57 +0200 fs r275398 : #i102631# when saving the document fails, ensure that the interaction handler really can handle/display the error 2009-08-26 09:37:05 +0200 fs r275397 : #i102631# don't let non-IO/RuntimeExceptions escape from DatabaseDocument::store*, wrap them into an IOException 2009-08-26 09:35:39 +0200 fs r275395 : let the default interaction handler implement XInteractionHandler2 2009-08-25 13:51:34 +0200 fs r275352 : #i102631# createTempFile: pass URL through FileHelper.getOOoCompatibleFileURL 2009-08-25 13:49:23 +0200 fs r275351 : #i102631# createTempFileURL: immediately delete the file implicitly created by createTempFile, we really only need the URL 2009-08-24 14:49:07 +0200 fs r275318 : #i10000# 2009-08-24 14:36:03 +0200 fs r275315 : properly terminate message with 0 character 2009-08-24 14:35:45 +0200 fs r275314 : trace method concepts in non-pro, if special flag is enabled 2009-08-24 14:24:17 +0200 fs r275312 : #i98973# filter some more events for grid control columns 2009-08-24 14:15:23 +0200 fs r275311 : #i98973# implement XComboBox for combo box cells 2009-08-24 13:39:24 +0200 fs r275308 : #i98973# do not display the 'actionPerformed' event for grid combo box columns 2009-08-24 12:52:03 +0200 fs r275303 : #i98973# implement XCheckBox and XButton for check box cells 2009-08-24 11:56:05 +0200 oj r275300 : #i104447# wrong default for orientation 2009-08-24 10:51:21 +0200 fs r275296 : in the script selector dialog, interpret a double click onto a function as OK 2009-08-24 10:50:56 +0200 fs r275295 : localize some to-be-displayed names, consolidate some code regarding form/control naming 2009-08-21 14:28:05 +0200 fs r275255 : #i98973# implement KeyListeners 2009-08-21 14:27:20 +0200 fs r275254 : #i98973# move the conversion VCL[Mouse|Key]Event->Awt[Mouse|Key]Event from vclxwindow.cxx to VCLUnoHelper 2009-08-21 14:08:50 +0200 fs r275248 : #i98973# implement Mouse- and MouseMotion-broadcasting 2009-08-21 13:31:08 +0200 fs r275244 : #i98973# implement text and change listeners at text cells 2009-08-21 12:47:38 +0200 fs r275234 : #i104399# some refactoring: If the MySQL Connector/OOo is installed, it registers for the sdbc:mysqlc: protocol (now known as DST_MYSQL_NATIVE_DIRECT). However, we do not want to display this in the UI, instead we display "MySQL" only, which collects DST_MYSQL_ODBC, DST_MYSQL_JDBC, and DST_MYSQL_NATIVE. 2009-08-21 12:45:18 +0200 fs r275232 : #i104399# also register for the sdbc:mysql:mysqlc protocol, decide at runtime (depending on the availability of sdbc:mysqlc:), whether it is really accepted. This prevents that the C/OOo extension needs to register *our* implementation name for the sdbc:mysql:mysqlc: protocol, which would be somewhat weird 2009-08-20 16:18:48 +0200 fs r275190 : merging the latest changes from CWS dba32f (which this CWS was created from) 2009-08-19 20:19:59 +0200 fs r275160 : add some spacing between the radios 2009-08-19 14:50:15 +0200 fs r275150 : #i98973# slightly refactoring the grid cell implementations, to prepare for proper events being fired. Implement focus events for the moment, more to come. 2009-08-19 10:53:38 +0200 fs r275142 : #i99936# initialize newly created models 2009-08-18 23:03:48 +0200 fs r275132 : merging latest changes from CWS dba32f 2009-08-18 15:14:08 +0200 fs r275110 : #i102819# SetColumnPos: SCROLL_CLIP is deadly here
2009-09-14 11:18:01 +00:00
long PreNotify( NotifyEvent& _rNEvt );
void SetListener( IPropertyLineListener* _pListener );
void SetObserver( IPropertyControlObserver* _pObserver );
void EnableHelpSection( bool _bEnable );
bool HasHelpSection() const;
void SetHelpText( const OUString& _rHelpText );
void SetHelpLineLimites( sal_Int32 _nMinLines, sal_Int32 _nMaxLines );
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
void Clear();
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
sal_uInt16 InsertEntry( const OLineDescriptor&, sal_uInt16 nPos = EDITOR_LIST_APPEND );
sal_Bool RemoveEntry( const OUString& _rName );
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
void ChangeEntry( const OLineDescriptor&, sal_uInt16 nPos );
void SetPropertyValue( const OUString& rEntryName, const ::com::sun::star::uno::Any& rValue, bool _bUnknownValue );
sal_uInt16 GetPropertyPos( const OUString& rEntryName ) const;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >
GetPropertyControl( const OUString& rEntryName );
void EnablePropertyControls( const OUString& _rEntryName, sal_Int16 _nControls, bool _bEnable );
void EnablePropertyLine( const OUString& _rEntryName, bool _bEnable );
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
sal_Int32 GetMinimumWidth();
sal_Int32 GetMinimumHeight();
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
sal_Bool IsModified( ) const;
void CommitModified( );
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
protected:
// IControlContext
virtual void SAL_CALL focusGained( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& Control ) throw (::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL valueChanged( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& Control ) throw (::com::sun::star::uno::RuntimeException);
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
virtual void SAL_CALL activateNextControl( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& CurrentControl ) throw (::com::sun::star::uno::RuntimeException);
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
// IButtonClickListener
void buttonClicked( OBrowserLine* _pLine, sal_Bool _bPrimary );
using Window::SetHelpText;
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
private:
DECL_LINK( ScrollHdl, ScrollBar* );
INTEGRATION: CWS pbrwuno (1.6.156); FILE MERGED 2005/10/24 08:41:37 fs 1.6.156.11: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.* 2005/10/19 07:48:04 fs 1.6.156.10: #i53095# knitting some loose ends 2005/10/14 12:43:44 fs 1.6.156.9: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values 2005/10/11 13:28:46 fs 1.6.156.8: #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/07 12:24:19 fs 1.6.156.7: #i53095# notifications to the IControlContext are asynchronous now - this prevents problems if such a notification causes the exchange of control/windows 2005/10/05 06:49:24 fs 1.6.156.6: RESYNC: (1.6-1.7); FILE MERGED 2005/09/05 07:41:47 fs 1.6.156.5: #i53095# phase 3, part 1: introduced XPropertyControl and relatives, describing one control in the ObjectInspector, responsible for one property known issues: - rebuildPropertyUI can cause problems now: If the user clicks into the control for property A, which causes property B to be committed, which causes the UI for property A to be rebuilt, then this will crash currently. Reason: rebuildPropertyUI now synchronously replaces the VCL-Window of the rebuilt control, which is exactly the one which is still in some MouseButtonDown-handler. possible solutions: - see if rebuiltPropertyUI can be obsoleted - handlers should be able to just obtain the XPropertyControl from the PropertyUI, and re-initialize the control. Shouldn't they?` - make one of the steps in the chain (mouse-click, handler-call, rebuildPropertyUI-callback) asynchronous. 2005/08/31 08:28:54 fs 1.6.156.4: #i53095# get rid of Set/GetPropertyName at the IBrowserControl 2005/08/12 16:30:07 fs 1.6.156.3: - 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/10 15:41:42 fs 1.6.156.2: #i53095# get rid of nearly all [1] the implementations in OPropertyBrowserController::Clicked, and move them to a FormComponentHandler [1] still to migrate: - browsing for events (needs a dedicated event property handler) - handling for clicking the button of the Command property - this is kind of asynchronous, and IPropertyHandler is not yet prepared for this 2005/08/09 13:59:54 fs 1.6.156.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:37 +00:00
/** retrieves the index of a given control in our line list
@param _rxControl
The control to lookup. Must denote a control of one of the lines in ->m_aLines
*/
sal_uInt16 impl_getControlPos( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& _rxControl ) const;
/** sets the given property value at the given control, after converting it as necessary
@param _rLine
The line whose at which the value is to be set.
@param _rPropertyValue
the property value to set. If it's not compatible with the control value,
it will be converted, using <member>XPropertyHandler::convertToControlValue</member>
*/
void impl_setControlAsPropertyValue( const ListBoxLine& _rLine, const ::com::sun::star::uno::Any& _rPropertyValue );
/** retrieves the value for the given control, as a property value, after converting it as necessary
@param _rLine
The line whose at which the value is to be set.
*/
::com::sun::star::uno::Any
impl_getControlAsPropertyValue( const ListBoxLine& _rLine ) const;
/** retrieves the ->BrowserLinePointer for a given entry name
@param _rEntryName
the name whose line is to be looked up
@param _out_rpLine
contains, upon return, the found browser line, if any
@return
<TRUE/> if and only if a non-<NULL/> line for the given entry name could be
found.
*/
bool impl_getBrowserLineForName( const OUString& _rEntryName, BrowserLinePointer& _out_rpLine ) const;
/** returns the preferred height (in pixels) of the help section, or 0 if we
currently don't have a help section
*/
long impl_getPrefererredHelpHeight();
private:
using Window::Activate;
};
//............................................................................
} // namespace pcr
//............................................................................
#endif // _EXTENSIONS_PROPCTRLR_BROWSERLISTBOX_HXX_
2010-10-27 12:45:03 +01:00
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */