2010-10-27 12:45:03 +01:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
|
re-base on ALv2 code. Includes (at least) relevant parts of:
linecap: Reintegrating finished LineCap feature
Patch contributed by Regina Henschel
http://svn.apache.org/viewvc?view=revision&revision=1232507
Patches contributed by Sven Jacobi
impress212: #i81610# fixed animation export
http://svn.apache.org/viewvc?view=revision&revision=1167620
impress212: drawinglayer gbuild environment changes
http://svn.apache.org/viewvc?view=revision&revision=1167627
http://svn.apache.org/viewvc?view=revision&revision=1167628
impress212: DffPropSet -> minor code improvements, removing table
http://svn.apache.org/viewvc?view=revision&revision=1167634
impress212: #158494# fixed excel import (text rotation)
http://svn.apache.org/viewvc?view=revision&revision=1167638
Patches contributed by Armin Le Grand
Svg: Reintegrated Svg replacement from /branches/alg/svgreplavement
http://svn.apache.org/viewvc?view=revision&revision=1220836
#118728# changed indentifying definitions for Svg file detection
http://svn.apache.org/viewvc?view=revision&revision=1229961
#118838# LineGeometry creation for complicated cases optimized to
create single Polygons
http://svn.apache.org/viewvc?view=revision&revision=1236232
#119176# corrected file type detection for SVG for svg files
without xml header
http://svn.apache.org/viewvc?view=revision&revision=1309445
#118728# Extended Svg file detection
http://svn.apache.org/viewvc?view=revision&revision=1230531
#118529# solve break converters and convert commands for OLEs and images
http://svn.apache.org/viewvc?view=revision&revision=1186168
svg: added WaE changes from branch svgreplacement to trunc
http://svn.apache.org/viewvc?view=revision&revision=1222974
svg: corrected missing member initialization
http://svn.apache.org/viewvc?view=revision&revision=1226134
fix for #118525#: Using primitives for chart sub-geometry visualisation
http://svn.apache.org/viewvc?view=revision&revision=1226879
#118898# Adapted ImpGraphic::ImplGetBitmap to correctly convert
metafiles to bitmapEx ...
http://svn.apache.org/viewvc?view=revision&revision=1293316
fix for #118525#: removed no longer used variable maOriginalMapMode, one
more exception eliminated
http://svn.apache.org/viewvc?view=revision&revision=1227097
#16758# Added buffering to the VDev usages of the VclProcessor2D derivates...
http://svn.apache.org/viewvc?view=revision&revision=1229521
#116758# Secured VDev buffer device to Vcl deinit
http://svn.apache.org/viewvc?view=revision&revision=1230574
#116758# added remembering allocated VDevs for VDevBuffer to be able to also
delete these when vcl goes down; it should never happen, but You never know
http://svn.apache.org/viewvc?view=revision&revision=1230927
#118730# Changed SvgClipPathNode to use MaskPrimitive2D for primitive
representation instead of TransparencePrimitive2D
http://svn.apache.org/viewvc?view=revision&revision=1231198
#118822# secured 3D geometry creation (slices) by subdividing the 2D
source polyPolygon early
http://svn.apache.org/viewvc?view=revision&revision=1234749
#118829# enhanced Svg gradient quality, obstacles avoided
http://svn.apache.org/viewvc?view=revision&revision=1235361
#118834# Unified usage of TextBreakupHelper as single tooling class
for i18n text primitive breakup
http://svn.apache.org/viewvc?view=revision&revision=1236110
#118853# added square pixel size limit to conversion of
TransparencePrimitive2D to Metafile action
http://svn.apache.org/viewvc?view=revision&revision=1237656
#118824# coreccted mirroring and boundrect when the graphicmanager
is used for bitmap output
http://svn.apache.org/viewvc?view=revision&revision=1240097
#115092# Corrected VclProcessor2D::RenderPolygonStrokePrimitive2D for
various optimization scenarios
http://svn.apache.org/viewvc?view=revision&revision=1241434
#118783# Corrected errors in ID strings, corrected Svg line/fill export,
corrected polygon close state
http://svn.apache.org/viewvc?view=revision&revision=1232006
#118796# corrected null-pointer usage in SVG text exporter
http://svn.apache.org/viewvc?view=revision&revision=1240262
#118729# Use GraphicStreamUrl and GraphicUrl to allow multi image
import with linked graphics, too
http://svn.apache.org/viewvc?view=revision&revision=1229962
#118898# corrected error in GDIMetaFile::GetBoundRect in handling
MetaFloatTransparentAction
http://svn.apache.org/viewvc?view=revision&revision=1293349
#118855# Corrected handling of possibly created empty clipRegions
after PolyPolygon clipping
http://svn.apache.org/viewvc?view=revision&revision=1237725
#115962# Better (but not yet optimal, see comments in task) handling
of MetaFloatTransparentAction in PDF export
http://svn.apache.org/viewvc?view=revision&revision=1241078
IP clearance: #118466# This patch removes librsvg, libcroco, libgsf, ...
http://svn.apache.org/viewvc?view=revision&revision=1200879
118779# Added svg content streaming in/out to ImpGraphic stream operators
http://svn.apache.org/viewvc?view=revision&revision=1231908
linecap: correctons for WaE and mac drawing
http://svn.apache.org/viewvc?view=revision&revision=1232793
svg: uses current system Dpi for Svg replacement image creation
http://svn.apache.org/viewvc?view=revision&revision=1233948
Patches contributed by Mathias Bauer (and others)
gnumake4 work variously
http://svn.apache.org/viewvc?view=revision&revision=1394326
http://svn.apache.org/viewvc?view=revision&revision=1396797
http://svn.apache.org/viewvc?view=revision&revision=1397315
http://svn.apache.org/viewvc?view=revision&revision=1394326
Remove duplicate header includes.
cws mba34issues01: #i117720#: convert assertion into warning
http://svn.apache.org/viewvc?view=revision&revision=1172352
118485 - Styles for OLEs are not saved. Submitted by Armin Le Grand.
http://svn.apache.org/viewvc?view=revision&revision=1182166
cws mba34issues01: #i117714#: remove assertion
http://svn.apache.org/viewvc?view=revision&revision=1172357
Patch contributed by Jurgen Schmidt
add some additional checks to ensure proper reading operations
http://svn.apache.org/viewvc?view=revision&revision=1209022
mostly prefer our stream / bounds checking work.
Patches contributed by Herbert Duerr
#i118816# add clarifying comment regarding Font::*Color*() methods
http://svn.apache.org/viewvc?view=revision&revision=1233833
extend macro->string handling for empty strings
http://svn.apache.org/viewvc?view=revision&revision=1175801
avoid magic constants for SALCOLOR_NONE
http://svn.apache.org/viewvc?view=revision&revision=1177543
initialize slant properly in ImplFontMetricData constructor (author=iorsh)
http://svn.apache.org/viewvc?view=revision&revision=1177551
#i118675# make check for extension updates more stable
http://svn.apache.org/viewvc?view=revision&revision=1214797
#a118617# remove VBasicEventListener.dll binary
There are no known users depending on its CLSID
http://svn.apache.org/viewvc?view=revision&revision=1203697
Patches contributed by Ariel Constenla-Haile
Fix build breaker on Linux/gcc
http://svn.apache.org/viewvc?view=revision&revision=1221104
Fix crash when trying to instantiate css.graphic.GraphicRasterizer_RSVG
http://svn.apache.org/viewvc?view=revision&revision=1215559
Patches contributed by Oliver-Rainer Wittmann
sw34bf06: #i117962# - method <SwFlyFrm::IsPaint(..)> - consider
instances of <SwFlyDrawObj>
http://svn.apache.org/viewvc?view=revision&revision=1172120
sw34bf06: #i117783# - Writer's implementation of XPagePrintable -
apply print settings to new printing routines
http://svn.apache.org/viewvc?view=revision&revision=1172115
gnumake4 work variously from Hans-Joachim Lankenau
http://svn.apache.org/viewvc?view=revision&revision=1397315
http://svn.apache.org/viewvc?view=revision&revision=1396797
http://svn.apache.org/viewvc?view=revision&revision=1396782
http://svn.apache.org/viewvc?view=revision&revision=1394707
plus some amount of re-splitting of legacy headers.
Patch contributed by Pavel Janik
WaE: Remove unused variables.
http://svn.apache.org/viewvc?view=revision&revision=1230697
Patches contributed by Takashi Ono
mingwport35: i#117795: MinGW port fix for vcl2gnumake
http://svn.apache.org/viewvc?view=revision&revision=1172091
mingwport35: i#117795: MinGW port fix for vcl2gnumake
http://svn.apache.org/viewvc?view=revision&revision=1172091
Patch contributed by Christian Lippka
impress212: #i98044# re enable Text menu for outline and title shapes
http://svn.apache.org/viewvc?view=revision&revision=1167639
Patch contributed by Andre Fischer
118674: Made category B code optional and disabled by default.
http://svn.apache.org/viewvc?view=revision&revision=1215131
118881: Ignore empty paragraphs after bullets.
http://svn.apache.org/viewvc?view=revision&revision=1296205
Patches contributed by Philipp Lohmann
ooo340fixes: #i117780# use rtl allocator
http://svn.apache.org/viewvc?view=revision&revision=1172087
ooo34gsl02: #i117807# fix an off by one error (index actually
inside the pfb section header)
http://svn.apache.org/viewvc?view=revision&revision=1167576
various cleanups, related compilation fixes, warning cleanups, re-working
of obsolete stl template pieces to use boost instead, changed string
classes, re-adapt KDE about data, about dialog, fixing warnings,
and other fixes & improvements.
Disable svg import / render for about/ branding code-paths for now.
Restore full icon theme set.
Remove OS/2 conditionals and sources.
Remove conflicting gtk/full-screen monitors support.
Retain existing svg rasterizer files - temporarily disabled.
Standardize stringificaiton and fixup dllpostfix issues.
Rename SvgGradientHelper::== to equalTo to avoid overloading issues.
Use the flat GdiPlus API for LineCaps calls.
2012-10-09 12:22:23 +01:00
|
|
|
/*
|
|
|
|
* This file is part of the LibreOffice project.
|
|
|
|
*
|
|
|
|
* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
*
|
|
|
|
* This file incorporates work covered by the following license notice:
|
|
|
|
*
|
|
|
|
* Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
* contributor license agreements. See the NOTICE file distributed
|
|
|
|
* with this work for additional information regarding copyright
|
|
|
|
* ownership. The ASF licenses this file to you under the Apache
|
|
|
|
* License, Version 2.0 (the "License"); you may not use this file
|
|
|
|
* except in compliance with the License. You may obtain a copy of
|
|
|
|
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
|
|
|
|
*/
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#ifndef INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PROPCONTROLLER_HXX
|
|
|
|
#define INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PROPCONTROLLER_HXX
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
#include "composeduiupdate.hxx"
|
|
|
|
#include "formbrowsertools.hxx"
|
|
|
|
#include "formmetadata.hxx"
|
|
|
|
#include "proplinelistener.hxx"
|
2006-12-13 11:02:20 +00:00
|
|
|
#include "propcontrolobserver.hxx"
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
#include "browserview.hxx"
|
|
|
|
#include "modulepcr.hxx"
|
|
|
|
#include "propertyinfo.hxx"
|
|
|
|
|
2001-05-30 12:41:46 +00:00
|
|
|
#include <com/sun/star/awt/XFocusListener.hpp>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <com/sun/star/beans/XPropertyState.hpp>
|
|
|
|
#include <com/sun/star/beans/XPropertySet.hpp>
|
2004-03-19 11:05:47 +00:00
|
|
|
#include <com/sun/star/beans/XPropertyChangeListener.hpp>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <com/sun/star/lang/XMultiServiceFactory.hpp>
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
#include <com/sun/star/uno/XComponentContext.hpp>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <com/sun/star/form/XForm.hpp>
|
2001-08-13 14:45:53 +00:00
|
|
|
#include <com/sun/star/sdbc/XRowSet.hpp>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <com/sun/star/uno/Sequence.hxx>
|
|
|
|
#include <com/sun/star/lang/XServiceInfo.hpp>
|
|
|
|
#include <com/sun/star/lang/XEventListener.hpp>
|
2001-08-06 13:52:59 +00:00
|
|
|
#include <com/sun/star/sdbc/XConnection.hpp>
|
2002-11-12 11:12:36 +00:00
|
|
|
#include <com/sun/star/awt/XLayoutConstrains.hpp>
|
2004-03-19 11:05:47 +00:00
|
|
|
#include <com/sun/star/awt/XControlContainer.hpp>
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
#include <com/sun/star/inspection/XPropertyControlFactory.hpp>
|
|
|
|
#include <com/sun/star/inspection/XObjectInspector.hpp>
|
|
|
|
#include <com/sun/star/inspection/XObjectInspectorUI.hpp>
|
|
|
|
#include <com/sun/star/inspection/XPropertyHandler.hpp>
|
2006-12-13 11:02:20 +00:00
|
|
|
#include <com/sun/star/lang/XInitialization.hpp>
|
2005-09-23 11:52:18 +00:00
|
|
|
#include <connectivity/dbtools.hxx>
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
#include <cppuhelper/interfacecontainer.hxx>
|
2015-08-04 17:52:31 +09:00
|
|
|
#include <cppuhelper/implbase.hxx>
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
#include <comphelper/broadcasthelper.hxx>
|
2004-11-16 11:10:28 +00:00
|
|
|
|
|
|
|
#include <map>
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
#include <memory>
|
2015-01-04 11:10:45 +00:00
|
|
|
#include <unordered_map>
|
|
|
|
#include <vector>
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-09-23 11:20:40 +02:00
|
|
|
namespace vcl { class Window; }
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
namespace pcr
|
|
|
|
{
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
class OPropertyEditor;
|
|
|
|
struct OLineDescriptor;
|
|
|
|
|
2015-09-30 11:48:44 +02:00
|
|
|
typedef ::cppu::WeakImplHelper < css::lang::XServiceInfo
|
|
|
|
, css::awt::XFocusListener
|
|
|
|
, css::awt::XLayoutConstrains
|
|
|
|
, css::beans::XPropertyChangeListener
|
|
|
|
, css::inspection::XPropertyControlFactory
|
|
|
|
, css::inspection::XObjectInspector
|
|
|
|
, css::lang::XInitialization
|
2001-01-12 10:35:45 +00:00
|
|
|
> OPropertyBrowserController_Base;
|
|
|
|
|
|
|
|
class OPropertyBrowserController
|
|
|
|
:public ::comphelper::OMutexAndBroadcastHelper
|
|
|
|
,public OPropertyBrowserController_Base
|
2015-09-30 11:48:44 +02:00
|
|
|
,public css::inspection::XObjectInspectorUI
|
2006-12-13 11:02:20 +00:00
|
|
|
// that's intentionally *not* part of the OPropertyBrowserController_Base
|
|
|
|
// We do not want this to be available in queryInterface, getTypes, and the like.
|
2001-01-12 10:35:45 +00:00
|
|
|
,public IPropertyLineListener
|
2006-12-13 11:02:20 +00:00
|
|
|
,public IPropertyControlObserver
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
,public IPropertyExistenceCheck
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
private:
|
2017-02-17 19:06:24 +02:00
|
|
|
typedef std::multimap< sal_Int32, css::beans::Property > OrderedPropertyMap;
|
|
|
|
typedef std::vector< css::uno::Reference< css::uno::XInterface > >
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
InterfaceArray;
|
2004-11-16 11:10:28 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
protected:
|
2015-09-30 11:48:44 +02:00
|
|
|
css::uno::Reference< css::uno::XComponentContext > m_xContext;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
private:
|
2015-09-30 11:48:44 +02:00
|
|
|
css::uno::Reference< css::frame::XFrame > m_xFrame;
|
|
|
|
css::uno::Reference< css::awt::XWindow > m_xView;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2016-01-19 19:45:45 +02:00
|
|
|
::comphelper::OInterfaceContainerHelper2 m_aDisposeListeners;
|
|
|
|
::comphelper::OInterfaceContainerHelper2 m_aControlObservers;
|
2001-01-12 10:35:45 +00:00
|
|
|
// meta data about the properties
|
2015-03-09 14:29:30 +02:00
|
|
|
VclPtr<OPropertyBrowserView> m_pView;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString m_sPageSelection;
|
|
|
|
OUString m_sLastValidPageSelection;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2015-09-30 11:48:44 +02:00
|
|
|
typedef css::uno::Reference< css::inspection::XPropertyHandler >
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
PropertyHandlerRef;
|
2017-02-17 19:06:24 +02:00
|
|
|
typedef std::vector< PropertyHandlerRef > PropertyHandlerArray;
|
2017-10-19 17:18:17 +02:00
|
|
|
typedef std::unordered_map< OUString, PropertyHandlerRef >
|
2004-11-16 11:10:28 +00:00
|
|
|
PropertyHandlerRepository;
|
2017-10-19 17:18:17 +02:00
|
|
|
typedef std::unordered_multimap< OUString, PropertyHandlerRef >
|
2004-11-16 11:10:28 +00:00
|
|
|
PropertyHandlerMultiRepository;
|
|
|
|
PropertyHandlerRepository m_aPropertyHandlers;
|
|
|
|
PropertyHandlerMultiRepository m_aDependencyHandlers;
|
2007-05-10 09:49:37 +00:00
|
|
|
PropertyHandlerRef m_xInteractiveHandler;
|
2004-11-16 11:10:28 +00:00
|
|
|
|
2017-02-17 19:06:24 +02:00
|
|
|
std::unique_ptr< ComposedPropertyUIUpdate > m_pUIRequestComposer;
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
|
|
|
|
/// our InspectorModel
|
2015-09-30 11:48:44 +02:00
|
|
|
css::uno::Reference< css::inspection::XObjectInspectorModel >
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
m_xModel;
|
|
|
|
/// the object(s) we're currently inspecting
|
|
|
|
InterfaceArray m_aInspectedObjects;
|
|
|
|
/// the properties of the currently inspected object(s)
|
|
|
|
OrderedPropertyMap m_aProperties;
|
2004-11-16 11:10:28 +00:00
|
|
|
/// the property we're just committing
|
2015-09-30 11:48:44 +02:00
|
|
|
OUString m_sCommittingProperty;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2017-10-19 17:18:17 +02:00
|
|
|
typedef std::unordered_map< OUString, sal_uInt16 > HashString2Int16;
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
HashString2Int16 m_aPageIds;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2006-12-13 11:02:20 +00:00
|
|
|
bool m_bContainerFocusListening;
|
|
|
|
bool m_bSuspendingPropertyHandlers;
|
|
|
|
bool m_bConstructed;
|
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
|
|
|
bool m_bBindingIntrospectee;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
protected:
|
2006-12-13 11:02:20 +00:00
|
|
|
DECLARE_XINTERFACE()
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
// XServiceInfo
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual OUString SAL_CALL getImplementationName( ) override;
|
|
|
|
virtual sal_Bool SAL_CALL supportsService( const OUString& ServiceName ) override;
|
|
|
|
virtual css::uno::Sequence< OUString > SAL_CALL getSupportedServiceNames( ) override;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
// XController
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual void SAL_CALL attachFrame( const css::uno::Reference< css::frame::XFrame >& xFrame ) override;
|
|
|
|
virtual sal_Bool SAL_CALL attachModel( const css::uno::Reference< css::frame::XModel >& xModel ) override;
|
|
|
|
virtual sal_Bool SAL_CALL suspend( sal_Bool bSuspend ) override;
|
|
|
|
virtual css::uno::Any SAL_CALL getViewData( ) override;
|
|
|
|
virtual void SAL_CALL restoreViewData( const css::uno::Any& Data ) override;
|
|
|
|
virtual css::uno::Reference< css::frame::XModel > SAL_CALL getModel( ) override;
|
|
|
|
virtual css::uno::Reference< css::frame::XFrame > SAL_CALL getFrame( ) override;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
// XComponent
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual void SAL_CALL dispose( ) override;
|
|
|
|
virtual void SAL_CALL addEventListener( const css::uno::Reference< css::lang::XEventListener >& xListener ) override;
|
|
|
|
virtual void SAL_CALL removeEventListener( const css::uno::Reference< css::lang::XEventListener >& aListener ) override;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2001-05-30 12:41:46 +00:00
|
|
|
// XFocusListener
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual void SAL_CALL focusGained( const css::awt::FocusEvent& _rSource ) override;
|
|
|
|
virtual void SAL_CALL focusLost( const css::awt::FocusEvent& _rSource ) override;
|
2001-05-30 12:41:46 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
// XEventListener
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual void SAL_CALL disposing( const css::lang::EventObject& Source ) override;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2015-09-30 11:06:04 +02:00
|
|
|
// XLayoutConstrains
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual css::awt::Size SAL_CALL getMinimumSize( ) override;
|
|
|
|
virtual css::awt::Size SAL_CALL getPreferredSize( ) override;
|
|
|
|
virtual css::awt::Size SAL_CALL calcAdjustedSize( const css::awt::Size& aNewSize ) override;
|
2001-12-13 08:14:26 +00:00
|
|
|
|
2004-03-19 11:05:47 +00:00
|
|
|
// XPropertyChangeListener
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual void SAL_CALL propertyChange( const css::beans::PropertyChangeEvent& _rEvent ) override;
|
2004-03-19 11:05:47 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** XPropertyControlFactory
|
|
|
|
*/
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual css::uno::Reference< css::inspection::XPropertyControl > SAL_CALL createPropertyControl( ::sal_Int16 ControlType, sal_Bool CreateReadOnly ) override;
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
public:
|
2015-10-18 07:53:51 +02:00
|
|
|
explicit OPropertyBrowserController(
|
2015-09-30 11:48:44 +02:00
|
|
|
const css::uno::Reference< css::uno::XComponentContext >& _rxContext);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
protected:
|
2016-09-13 13:09:01 +02:00
|
|
|
virtual ~OPropertyBrowserController() override;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
public:
|
2001-01-12 10:35:45 +00:00
|
|
|
// XServiceInfo - static versions
|
2017-01-19 17:57:50 +01:00
|
|
|
/// @throws css::uno::RuntimeException
|
2017-01-26 12:28:58 +01:00
|
|
|
static OUString getImplementationName_static( );
|
2017-01-19 17:57:50 +01:00
|
|
|
/// @throws css::uno::RuntimeException
|
2017-01-26 12:28:58 +01:00
|
|
|
static css::uno::Sequence< OUString > getSupportedServiceNames_static( );
|
No need to keep these whitelisted functions decorated with SAL_CALL
The only effect SAL_CALL effectively has on LO-internal code is to change non-
static member functions from __thiscall to __cdecl in MSVC (where all other
functions are __cdecl by default, anyway). (For 3rd-party code, it could be
argued that SAL_CALL is useful on function declarations in the URE stable
interface other than non-static member functions, too, in case 3rd-party code
uses a compiler switch to change the default calling convention to something
other than __cdecl. But loplugin:salcall exempts the URE stable interface,
anyway.)
One could argue that SAL_CALL, even if today it effectively only affects non-
static member functions in MSVC, could be extended in the future to affect more
functions on more platforms. However, the current code would already not
support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c
"loplugin:salcall fix functions" changed FrameControl_createInstance in
UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even
though its address (in ctl_component_getFacrory, in the same file) is passed to
cppuhelper::createSingleFactory as an argument of type
cppu::ComponentInstantiation, which is a pointer to SAL_CALL function.
Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6
Reviewed-on: https://gerrit.libreoffice.org/46436
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-14 08:45:02 +01:00
|
|
|
static css::uno::Reference< css::uno::XInterface >
|
2015-09-30 11:48:44 +02:00
|
|
|
Create(const css::uno::Reference< css::uno::XComponentContext >&);
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
protected:
|
|
|
|
// IPropertyLineListener
|
2015-10-12 16:04:04 +02:00
|
|
|
virtual void Clicked( const OUString& _rName, bool _bPrimary ) override;
|
|
|
|
virtual void Commit( const OUString& _rName, const css::uno::Any& _rVal ) override;
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
|
2006-12-13 11:02:20 +00:00
|
|
|
// IPropertyControlObserver
|
2016-04-17 11:49:49 +02:00
|
|
|
virtual void focusGained( const css::uno::Reference< css::inspection::XPropertyControl >& Control ) override;
|
|
|
|
virtual void valueChanged( const css::uno::Reference< css::inspection::XPropertyControl >& Control ) override;
|
2006-12-13 11:02:20 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
// IPropertyExistenceCheck
|
2017-12-05 10:11:39 +02:00
|
|
|
virtual bool hasPropertyByName( const OUString& _rName ) override;
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
|
|
|
|
// XObjectInspectorUI
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual void SAL_CALL enablePropertyUI( const OUString& _rPropertyName, sal_Bool _bEnable ) override;
|
|
|
|
virtual void SAL_CALL enablePropertyUIElements( const OUString& _rPropertyName, ::sal_Int16 _nElements, sal_Bool _bEnable ) override;
|
|
|
|
virtual void SAL_CALL rebuildPropertyUI( const OUString& _rPropertyName ) override;
|
|
|
|
virtual void SAL_CALL showPropertyUI( const OUString& _rPropertyName ) override;
|
|
|
|
virtual void SAL_CALL hidePropertyUI( const OUString& _rPropertyName ) override;
|
|
|
|
virtual void SAL_CALL showCategory( const OUString& _rCategory, sal_Bool _bShow ) override;
|
|
|
|
virtual css::uno::Reference< css::inspection::XPropertyControl > SAL_CALL getPropertyControl( const OUString& _rPropertyName ) override;
|
|
|
|
virtual void SAL_CALL registerControlObserver( const css::uno::Reference< css::inspection::XPropertyControlObserver >& Observer ) override;
|
|
|
|
virtual void SAL_CALL revokeControlObserver( const css::uno::Reference< css::inspection::XPropertyControlObserver >& Observer ) override;
|
|
|
|
virtual void SAL_CALL setHelpSectionText( const OUString& HelpText ) override;
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
|
|
|
|
// XObjectInspector
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual css::uno::Reference< css::inspection::XObjectInspectorModel > SAL_CALL getInspectorModel() override;
|
|
|
|
virtual void SAL_CALL setInspectorModel( const css::uno::Reference< css::inspection::XObjectInspectorModel >& _inspectormodel ) override;
|
|
|
|
virtual css::uno::Reference< css::inspection::XObjectInspectorUI > SAL_CALL getInspectorUI() override;
|
|
|
|
virtual void SAL_CALL inspect( const css::uno::Sequence< css::uno::Reference< css::uno::XInterface > >& Objects ) override;
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
|
|
|
|
// XDispatchProvider
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual css::uno::Reference< css::frame::XDispatch > SAL_CALL queryDispatch( const css::util::URL& URL, const OUString& TargetFrameName, ::sal_Int32 SearchFlags ) override;
|
|
|
|
virtual css::uno::Sequence< css::uno::Reference< css::frame::XDispatch > > SAL_CALL queryDispatches( const css::uno::Sequence< css::frame::DispatchDescriptor >& Requests ) override;
|
2004-11-16 11:10:28 +00:00
|
|
|
|
2006-12-13 11:02:20 +00:00
|
|
|
// XInitialization
|
2017-01-26 12:28:58 +01:00
|
|
|
virtual void SAL_CALL initialize( const css::uno::Sequence< css::uno::Any >& aArguments ) override;
|
2006-12-13 11:02:20 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
private:
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
void UpdateUI();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2001-05-30 12:41:46 +00:00
|
|
|
void startContainerWindowListening();
|
|
|
|
void stopContainerWindowListening();
|
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
// stop the inspection
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
void stopInspection( bool _bCommitModified );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2015-03-09 14:29:30 +02:00
|
|
|
bool haveView() const { return nullptr != m_pView; }
|
2006-12-13 11:02:20 +00:00
|
|
|
OPropertyEditor& getPropertyBox() { return m_pView->getPropertyBox(); }
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
// does the inspection of the objects as indicated by our model
|
|
|
|
void doInspection();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2004-11-16 11:10:28 +00:00
|
|
|
// bind the browser to m_xIntrospecteeAsProperty
|
2007-05-10 09:49:37 +00:00
|
|
|
void impl_rebindToInspectee_nothrow( const InterfaceArray& _rObjects );
|
2003-10-21 08:06:45 +00:00
|
|
|
|
2004-11-16 11:10:28 +00:00
|
|
|
/** retrieves special property handlers for our introspectee
|
2003-10-21 08:06:45 +00:00
|
|
|
*/
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
void getPropertyHandlers( const InterfaceArray& _rObjects, PropertyHandlerArray& _rHandlers );
|
2004-04-13 10:24:38 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** called when a property changed, to broadcast any handlers which might have
|
|
|
|
registered for this property
|
2004-11-26 17:27:01 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
@param _bFirstTimeInit
|
|
|
|
if set to <FALSE/>, this is a real change in the property value, not just a call
|
|
|
|
for purposes of initialization.
|
2003-10-21 08:06:45 +00:00
|
|
|
*/
|
2015-09-30 11:48:44 +02:00
|
|
|
void impl_broadcastPropertyChange_nothrow( const OUString& _rPropertyName, const css::uno::Any& _rNewValue, const css::uno::Any& _rOldValue, bool _bFirstTimeInit ) const;
|
2003-10-21 08:06:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** determines whether the given property is an actuating property, that is, at least one
|
|
|
|
handler expressed interest in changes to this property's value.
|
2004-03-19 11:05:47 +00:00
|
|
|
*/
|
2017-03-03 20:57:02 +01:00
|
|
|
bool impl_isActuatingProperty_nothrow( const OUString& _rPropertyName ) const
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
{
|
|
|
|
return ( m_aDependencyHandlers.find( _rPropertyName ) != m_aDependencyHandlers.end() );
|
|
|
|
}
|
2001-04-12 05:28:14 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** retrieves the value of the given property, by asking the appropriate XPropertyHandler
|
|
|
|
@param _rPropertyName
|
|
|
|
the name whose handler is to be obtained. Must be the name of a property
|
|
|
|
for which a handler is registered.
|
|
|
|
@throws
|
|
|
|
RuntimeException if there is no handler for the given property
|
|
|
|
@return
|
|
|
|
the value of this property
|
2004-11-16 11:10:28 +00:00
|
|
|
*/
|
2015-09-30 11:48:44 +02:00
|
|
|
css::uno::Any
|
2013-04-07 12:06:47 +02:00
|
|
|
impl_getPropertyValue_throw( const OUString& _rPropertyName );
|
2004-11-16 11:10:28 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/// calls XPropertyHandler::suspend for all our property handlers
|
2014-05-08 11:41:58 +02:00
|
|
|
bool suspendPropertyHandlers_nothrow( bool _bSuspend );
|
2001-02-19 13:08:05 +00:00
|
|
|
|
2007-05-10 09:49:37 +00:00
|
|
|
/// suspends the complete inspector
|
2014-05-08 11:41:58 +02:00
|
|
|
bool suspendAll_nothrow();
|
2007-05-10 09:49:37 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** selects a page according to our current view data
|
|
|
|
*/
|
|
|
|
void selectPageFromViewData();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** updates our view data from the currently active page
|
|
|
|
*/
|
|
|
|
void updateViewDataFromActivePage();
|
2004-03-19 11:05:47 +00:00
|
|
|
|
2004-11-16 11:10:28 +00:00
|
|
|
/// describes the UI for the given property
|
2015-09-30 11:48:44 +02:00
|
|
|
void describePropertyLine( const css::beans::Property& _rPropertyName, OLineDescriptor& _rDescriptor );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** retrieves the position of the property given by name in m_aProperties
|
|
|
|
@return
|
|
|
|
<TRUE/> if and only if the property could be found. In this case, <arg>_pProperty</arg> (if
|
|
|
|
not <NULL/> contains the iterator pointing to this property.
|
2004-03-19 11:05:47 +00:00
|
|
|
*/
|
2015-11-10 10:14:53 +01:00
|
|
|
bool impl_findObjectProperty_nothrow( const OUString& _rName, OrderedPropertyMap::const_iterator* _pProperty = nullptr );
|
2004-03-19 11:05:47 +00:00
|
|
|
|
2018-08-15 15:11:25 +02:00
|
|
|
void Construct(vcl::Window* _pParentWin);
|
2004-11-16 11:10:28 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** retrieves the property handler for a given property name
|
|
|
|
@param _rPropertyName
|
|
|
|
the name whose handler is to be obtained. Must be the name of a property
|
|
|
|
for which a handler is registered.
|
|
|
|
@throws
|
|
|
|
RuntimeException if there is no handler for the given property
|
|
|
|
@return
|
|
|
|
the handler which is responsible for the given property
|
2004-11-16 11:10:28 +00:00
|
|
|
*/
|
2017-12-30 14:36:04 +02:00
|
|
|
PropertyHandlerRef const &
|
2013-04-07 12:06:47 +02:00
|
|
|
impl_getHandlerForProperty_throw( const OUString& _rPropertyName ) const;
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
|
2006-07-26 06:59:09 +00:00
|
|
|
/** determines whether we have a handler for the given property
|
|
|
|
@param _rPropertyName
|
|
|
|
the name of the property for which the existence of a handler should be checked
|
|
|
|
*/
|
|
|
|
bool
|
2013-04-07 12:06:47 +02:00
|
|
|
impl_hasPropertyHandlerFor_nothrow( const OUString& _rPropertyName ) const;
|
2006-07-26 06:59:09 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** builds up m_aPageIds from InspectorModel::describeCategories, and insert all the
|
|
|
|
respective tab pages into our view
|
|
|
|
@precond
|
|
|
|
m_aPageIds is empty
|
2015-09-30 11:48:44 +02:00
|
|
|
@throws css::uno::RuntimeException
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
if one of the callees of this method throws this exception
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
impl_buildCategories_throw();
|
|
|
|
|
|
|
|
/** retrieves the id of the tab page which represents a given category.
|
|
|
|
@param _rCategoryName
|
|
|
|
the programmatic name of a category.
|
|
|
|
@return
|
|
|
|
the id of the tab page, or <code>(sal_uInt16)-1</code> if there
|
|
|
|
is no tab page for the given category
|
2004-11-16 11:10:28 +00:00
|
|
|
*/
|
|
|
|
sal_uInt16
|
2013-04-07 12:06:47 +02:00
|
|
|
impl_getPageIdForCategory_nothrow( const OUString& _rCategoryName ) const;
|
2004-03-19 11:05:47 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.27.38); FILE MERGED
2006/03/09 14:14:29 fs 1.27.38.23: #i62967# no UnknownPropertyExceptions at the XObjectInspectorUI anymore
2005/12/19 12:21:17 fs 1.27.38.22: #i53095# allow for the model's category description sequence to be empty - in this case, have a default fallback with using the property-handler-provided categories
2005/10/31 13:45:58 fs 1.27.38.21: some cleanup
2005/10/31 11:13:07 fs 1.27.38.20: teach the ComposedPropertyUIUpdate to handle missing properties
2005/10/26 14:03:33 fs 1.27.38.19: some cleanups for finalizing #i53095#
2005/10/25 11:52:44 fs 1.27.38.18: #i53095# some exception specifications, and some conceptual changes for multiple handlers supporting the same property
2005/10/24 08:42:02 fs 1.27.38.17: start making the handlers full-fledged components, with using a new infrastructure replacing extensions/source/inc/componentmodule.*
2005/10/17 14:19:01 fs 1.27.38.16: #i53095# some cleanup of remaining TODOs
2005/10/17 14:09:34 fs 1.27.38.15: #i53095# some cleanup of remaining TODOs
2005/10/17 08:17:02 fs 1.27.38.14: #i53095#
2005/10/14 12:43:47 fs 1.27.38.13: #i53095# properly care for MAYBEVOID properties and AMBIGUOUS property values
2005/10/14 10:48:03 fs 1.27.38.12: #i53095# replace InspectorModel::InspectedObjects with Inspector::inspect
2005/10/14 09:37:22 fs 1.27.38.11: #i53095# let the ObjectInspectorModel provide relative property ordering
2005/10/14 08:40:43 fs 1.27.38.10: #i53095# let the XObjectInspectorModel provide category meta information part
2005/10/13 13:01:09 fs 1.27.38.9: #i53095# introduce an XObjectInspector/Model
2005/10/11 13:29:36 fs 1.27.38.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/05 07:06:34 fs 1.27.38.7: RESYNC: (1.27-1.29); FILE MERGED
2005/09/05 07:41:53 fs 1.27.38.6: #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/18 12:44:33 fs 1.27.38.5: #i53095#, phase 2
moved (nearly) all property handling to dedicated handlers, the controller is
now simply managing a set of handlers
open issues for making the property browser completely generic:
- target page for a property - at the moment, the pbrw uses form-specific
knowledge
- relative position of properties. Again, the pbrw uses the OPropertyInfoService
which is not generic
- isComposeable for a given property. Also OPropertyInfoService-dependent ATM
- help ids of pages and the pbrw as a whole. They're hard-coded at the moment
other open issues:
everything in the code which is tagged with TOD/UNOize. Those are items which
do not immediately hinder phase 3 (real UNOization, i.e. definition of new
UNO interfaces for the handlers, the controller, and so on), but need to be
addressed in phase 4 (knit lose ends)
2005/08/16 05:39:04 fs 1.27.38.4: #i53095# completely moved the handling of actuating properties into dedicated handlers
2005/08/12 16:30:13 fs 1.27.38.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:47 fs 1.27.38.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 14:00:04 fs 1.27.38.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:29:34 +00:00
|
|
|
/** adds or removes ourself as XEventListener to/from all our inspectees
|
|
|
|
*/
|
|
|
|
void impl_toggleInspecteeListening_nothrow( bool _bOn );
|
2001-10-19 11:58:51 +00:00
|
|
|
|
2006-12-13 11:02:20 +00:00
|
|
|
/** binds the instance to a new model
|
|
|
|
*/
|
2015-09-30 11:48:44 +02:00
|
|
|
void impl_bindToNewModel_nothrow( const css::uno::Reference< css::inspection::XObjectInspectorModel >& _rxInspectorModel );
|
2006-12-13 11:02:20 +00:00
|
|
|
|
|
|
|
/** initializes our view, as indicated by the model's view-relevant properties
|
|
|
|
|
|
|
|
It's allowed to call this method when no model exists, yet. In this case, nothing
|
|
|
|
happens.
|
|
|
|
*/
|
|
|
|
void impl_initializeView_nothrow();
|
|
|
|
|
2007-05-10 09:49:37 +00:00
|
|
|
/** determines whether the view should be readonly.
|
|
|
|
|
|
|
|
Effectively, this means that the method simply checks the IsReadOnly attribute of the model.
|
|
|
|
If there is no model, <FALSE/> is returned.
|
|
|
|
|
2015-09-30 11:48:44 +02:00
|
|
|
@throws css::uno::RuntimeException
|
|
|
|
in case asking the model for its IsReadOnly attribute throws a css::uno::RuntimeException
|
2007-05-10 09:49:37 +00:00
|
|
|
itself.
|
|
|
|
*/
|
|
|
|
bool impl_isReadOnlyModel_throw() const;
|
|
|
|
|
|
|
|
/** starts or stops listening at the model
|
|
|
|
*/
|
|
|
|
void impl_startOrStopModelListening_nothrow( bool _bDoListen ) const;
|
|
|
|
|
2001-02-19 13:08:05 +00:00
|
|
|
private:
|
2016-10-05 07:56:12 +02:00
|
|
|
DECL_LINK(OnPageActivation, LinkParamNone*, void);
|
2006-12-13 11:02:20 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
// constructors
|
2015-09-30 11:48:44 +02:00
|
|
|
void createWithModel( const css::uno::Reference< css::inspection::XObjectInspectorModel >& _rxModel );
|
2001-01-12 10:35:45 +00:00
|
|
|
};
|
|
|
|
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
} // namespace pcr
|
2014-02-25 18:36:00 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-04-18 20:41:29 +02:00
|
|
|
#endif // INCLUDED_EXTENSIONS_SOURCE_PROPCTRLR_PROPCONTROLLER_HXX
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2010-10-27 12:45:03 +01:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|