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>
|
|
|
|
#include <com/sun/star/script/XEventAttacherManager.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/frame/XController.hpp>
|
|
|
|
#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>
|
|
|
|
#include <cppuhelper/implbase7.hxx>
|
|
|
|
#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;
|
|
|
|
|
2002-11-12 11:12:36 +00:00
|
|
|
// #95343#------------------------------------------------------------------------------------
|
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
|
|
|
typedef ::cppu::WeakImplHelper7 < ::com::sun::star::lang::XServiceInfo
|
2001-05-30 12:41:46 +00:00
|
|
|
, ::com::sun::star::awt::XFocusListener
|
2001-12-13 08:14:26 +00:00
|
|
|
, ::com::sun::star::awt::XLayoutConstrains
|
2004-03-19 11:05:47 +00:00
|
|
|
, ::com::sun::star::beans::XPropertyChangeListener
|
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
|
|
|
, ::com::sun::star::inspection::XPropertyControlFactory
|
|
|
|
, ::com::sun::star::inspection::XObjectInspector
|
2006-12-13 11:02:20 +00:00
|
|
|
, ::com::sun::star::lang::XInitialization
|
2001-01-12 10:35:45 +00:00
|
|
|
> OPropertyBrowserController_Base;
|
|
|
|
|
|
|
|
class OPropertyBrowserController
|
|
|
|
:public ::comphelper::OMutexAndBroadcastHelper
|
|
|
|
,public OPropertyBrowserController_Base
|
2006-12-13 11:02:20 +00:00
|
|
|
,public ::com::sun::star::inspection::XObjectInspectorUI
|
|
|
|
// 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:
|
2013-02-15 10:07:30 +01:00
|
|
|
typedef ::std::multimap< sal_Int32, ::com::sun::star::beans::Property > OrderedPropertyMap;
|
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
|
|
|
typedef ::std::vector< ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > >
|
|
|
|
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:
|
2013-06-03 15:34:00 +02:00
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::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:
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::frame::XFrame > m_xFrame;
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::awt::XWindow > m_xView;
|
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
|
|
|
::cppu::OInterfaceContainerHelper m_aDisposeListeners;
|
2006-12-13 11:02:20 +00:00
|
|
|
::cppu::OInterfaceContainerHelper 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
|
|
|
|
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
|
|
|
typedef ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyHandler >
|
|
|
|
PropertyHandlerRef;
|
2004-11-16 11:10:28 +00:00
|
|
|
typedef ::std::vector< PropertyHandlerRef > PropertyHandlerArray;
|
2015-01-04 11:10:45 +00:00
|
|
|
typedef std::unordered_map< OUString, PropertyHandlerRef, OUStringHash >
|
2004-11-16 11:10:28 +00:00
|
|
|
PropertyHandlerRepository;
|
2015-01-04 11:10:45 +00:00
|
|
|
typedef std::unordered_multimap< OUString, PropertyHandlerRef, OUStringHash >
|
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
|
|
|
|
2014-09-30 12:26:40 +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
|
|
|
|
::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorModel >
|
|
|
|
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
|
2013-04-07 12:06:47 +02:00
|
|
|
OUString m_sCommittingProperty;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2015-01-04 11:10:45 +00:00
|
|
|
typedef std::unordered_map< OUString, sal_uInt16, OUStringHash > 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
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual OUString SAL_CALL getImplementationName( ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual sal_Bool SAL_CALL supportsService( const OUString& ServiceName ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::uno::Sequence< OUString > SAL_CALL getSupportedServiceNames( ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
// XController
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void SAL_CALL attachFrame( const ::com::sun::star::uno::Reference< ::com::sun::star::frame::XFrame >& xFrame ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual sal_Bool SAL_CALL attachModel( const ::com::sun::star::uno::Reference< ::com::sun::star::frame::XModel >& xModel ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual sal_Bool SAL_CALL suspend( sal_Bool bSuspend ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::uno::Any SAL_CALL getViewData( ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL restoreViewData( const ::com::sun::star::uno::Any& Data ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::frame::XModel > SAL_CALL getModel( ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::frame::XFrame > SAL_CALL getFrame( ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
|
|
|
// XComponent
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void SAL_CALL dispose( ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL addEventListener( const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XEventListener >& xListener ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL removeEventListener( const ::com::sun::star::uno::Reference< ::com::sun::star::lang::XEventListener >& aListener ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2001-05-30 12:41:46 +00:00
|
|
|
// XFocusListener
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void SAL_CALL focusGained( const ::com::sun::star::awt::FocusEvent& _rSource ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL focusLost( const ::com::sun::star::awt::FocusEvent& _rSource ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2001-05-30 12:41:46 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
// XEventListener
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void SAL_CALL disposing( const ::com::sun::star::lang::EventObject& Source ) throw(::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2002-11-12 11:12:36 +00:00
|
|
|
// XLayoutConstrains #95343# ----------------
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual ::com::sun::star::awt::Size SAL_CALL getMinimumSize( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::awt::Size SAL_CALL getPreferredSize( ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::awt::Size SAL_CALL calcAdjustedSize( const ::com::sun::star::awt::Size& aNewSize ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2001-12-13 08:14:26 +00:00
|
|
|
|
2004-03-19 11:05:47 +00:00
|
|
|
// XPropertyChangeListener
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void SAL_CALL propertyChange( const ::com::sun::star::beans::PropertyChangeEvent& _rEvent ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_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
|
|
|
|
*/
|
2014-04-03 13:52:06 +02:00
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl > SAL_CALL createPropertyControl( ::sal_Int16 ControlType, sal_Bool CreateReadOnly ) throw (::com::sun::star::lang::IllegalArgumentException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_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:
|
|
|
|
OPropertyBrowserController(
|
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
|
|
|
const ::com::sun::star::uno::Reference< ::com::sun::star::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:
|
|
|
|
virtual ~OPropertyBrowserController();
|
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
|
2013-04-07 12:06:47 +02:00
|
|
|
static OUString getImplementationName_static( ) throw(::com::sun::star::uno::RuntimeException);
|
|
|
|
static ::com::sun::star::uno::Sequence< OUString > getSupportedServiceNames_static( ) throw(::com::sun::star::uno::RuntimeException);
|
2001-01-12 10:35:45 +00:00
|
|
|
static ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > SAL_CALL
|
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
|
|
|
Create(const ::com::sun::star::uno::Reference< ::com::sun::star::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
|
2014-09-12 15:23:48 +02:00
|
|
|
virtual void Clicked( const OUString& _rName, bool _bPrimary ) SAL_OVERRIDE;
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void Commit( const OUString& _rName, const ::com::sun::star::uno::Any& _rVal ) SAL_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
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void focusGained( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& _Control ) SAL_OVERRIDE;
|
|
|
|
virtual void valueChanged( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl >& _Control ) SAL_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
|
2014-09-12 15:23:48 +02:00
|
|
|
virtual bool SAL_CALL hasPropertyByName( const OUString& _rName ) throw (::com::sun::star::uno::RuntimeException) SAL_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
|
2014-04-03 13:52:06 +02:00
|
|
|
virtual void SAL_CALL enablePropertyUI( const OUString& _rPropertyName, sal_Bool _bEnable ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL enablePropertyUIElements( const OUString& _rPropertyName, ::sal_Int16 _nElements, sal_Bool _bEnable ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void SAL_CALL rebuildPropertyUI( const OUString& _rPropertyName ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL showPropertyUI( const OUString& _rPropertyName ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL hidePropertyUI( const OUString& _rPropertyName ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2014-04-03 13:52:06 +02:00
|
|
|
virtual void SAL_CALL showCategory( const OUString& _rCategory, sal_Bool _bShow ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControl > SAL_CALL getPropertyControl( const OUString& _rPropertyName ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL registerControlObserver( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlObserver >& _Observer ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL revokeControlObserver( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XPropertyControlObserver >& _Observer ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL setHelpSectionText( const OUString& HelpText ) throw (::com::sun::star::lang::NoSupportException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_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
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorModel > SAL_CALL getInspectorModel() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL setInspectorModel( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorModel >& _inspectormodel ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorUI > SAL_CALL getInspectorUI() throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual void SAL_CALL inspect( const ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Reference< ::com::sun::star::uno::XInterface > >& Objects ) throw (::com::sun::star::util::VetoException, ::com::sun::star::uno::RuntimeException, std::exception) SAL_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
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual ::com::sun::star::uno::Reference< ::com::sun::star::frame::XDispatch > SAL_CALL queryDispatch( const ::com::sun::star::util::URL& URL, const OUString& TargetFrameName, ::sal_Int32 SearchFlags ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
|
|
|
virtual ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Reference< ::com::sun::star::frame::XDispatch > > SAL_CALL queryDispatches( const ::com::sun::star::uno::Sequence< ::com::sun::star::frame::DispatchDescriptor >& Requests ) throw (::com::sun::star::uno::RuntimeException, std::exception) SAL_OVERRIDE;
|
2004-11-16 11:10:28 +00:00
|
|
|
|
2006-12-13 11:02:20 +00:00
|
|
|
// XInitialization
|
2014-03-27 18:12:18 +01:00
|
|
|
virtual void SAL_CALL initialize( const ::com::sun::star::uno::Sequence< ::com::sun::star::uno::Any >& aArguments ) throw (::com::sun::star::uno::Exception, ::com::sun::star::uno::RuntimeException, std::exception) SAL_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
|
|
|
*/
|
2013-04-07 12:06:47 +02:00
|
|
|
void impl_broadcastPropertyChange_nothrow( const OUString& _rPropertyName, const ::com::sun::star::uno::Any& _rNewValue, const ::com::sun::star::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
|
|
|
*/
|
2013-04-07 12:06:47 +02:00
|
|
|
inline 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
|
|
|
|
2013-04-07 12:06:47 +02:00
|
|
|
sal_uInt32 GetPropertyPos(const OUString& _rPropName);
|
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 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
|
|
|
*/
|
2003-10-21 08:06:45 +00:00
|
|
|
::com::sun::star::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
|
2014-06-05 08:15:03 +02:00
|
|
|
void describePropertyLine( const ::com::sun::star::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
|
|
|
*/
|
2013-04-07 12:06:47 +02:00
|
|
|
bool impl_findObjectProperty_nothrow( const OUString& _rName, OrderedPropertyMap::const_iterator* _pProperty = NULL );
|
2004-03-19 11:05:47 +00:00
|
|
|
|
2014-09-23 11:20:40 +02:00
|
|
|
bool 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
|
|
|
*/
|
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
|
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
|
|
|
|
@throws ::com::sun::star::uno::RuntimeException
|
|
|
|
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
|
|
|
|
*/
|
|
|
|
void impl_bindToNewModel_nothrow( const ::com::sun::star::uno::Reference< ::com::sun::star::inspection::XObjectInspectorModel >& _rxInspectorModel );
|
|
|
|
|
|
|
|
/** 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.
|
|
|
|
|
|
|
|
@throws ::com::sun::star::uno::RuntimeException
|
|
|
|
in case asking the model for its IsReadOnly attribute throws a ::com::sun::star::uno::RuntimeException
|
|
|
|
itself.
|
|
|
|
*/
|
|
|
|
bool impl_isReadOnlyModel_throw() const;
|
|
|
|
|
|
|
|
/** updates our view so that it is read-only, as indicated by the model property
|
|
|
|
@see impl_isReadOnlyModel_throw
|
|
|
|
*/
|
|
|
|
void impl_updateReadOnlyView_nothrow();
|
|
|
|
|
|
|
|
/** starts or stops listening at the model
|
|
|
|
*/
|
|
|
|
void impl_startOrStopModelListening_nothrow( bool _bDoListen ) const;
|
|
|
|
|
2001-02-19 13:08:05 +00:00
|
|
|
private:
|
|
|
|
DECL_LINK(OnPageActivation, void*);
|
2006-12-13 11:02:20 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
// constructors
|
|
|
|
void createDefault();
|
|
|
|
void createWithModel( const ::com::sun::star::uno::Reference< ::com::sun::star::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: */
|