2010-10-12 15:57:08 +02: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
|
|
|
|
|
|
|
#include "browserline.hxx"
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
|
2012-05-26 13:53:19 +02:00
|
|
|
#include <com/sun/star/uno/XComponentContext.hpp>
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
#include <com/sun/star/inspection/PropertyLineElement.hpp>
|
2012-05-26 13:53:19 +02:00
|
|
|
#include <com/sun/star/graphic/GraphicProvider.hpp>
|
2007-08-03 12:52:21 +00:00
|
|
|
#include <com/sun/star/graphic/XGraphicProvider.hpp>
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
|
2011-11-22 23:40:24 +00:00
|
|
|
#include <comphelper/processfactory.hxx>
|
|
|
|
#include <comphelper/string.hxx>
|
2001-01-12 10:35:45 +00:00
|
|
|
#include <tools/debug.hxx>
|
2007-08-03 12:52:21 +00:00
|
|
|
#include <tools/diagnose_ex.h>
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
#include <toolkit/helper/vclunohelper.hxx>
|
2011-11-22 23:40:24 +00:00
|
|
|
#include <vcl/svapp.hxx>
|
2014-01-02 23:52:37 +01:00
|
|
|
#include <vcl/settings.hxx>
|
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
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
using ::com::sun::star::uno::Reference;
|
2012-05-26 13:53:19 +02:00
|
|
|
using ::com::sun::star::uno::XComponentContext;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
using ::com::sun::star::inspection::XPropertyControl;
|
|
|
|
using ::com::sun::star::inspection::XPropertyControlContext;
|
|
|
|
using ::com::sun::star::uno::UNO_QUERY_THROW;
|
|
|
|
using ::com::sun::star::uno::Exception;
|
2012-05-26 13:53:19 +02:00
|
|
|
using ::com::sun::star::graphic::GraphicProvider;
|
2007-08-03 12:52:21 +00:00
|
|
|
using ::com::sun::star::graphic::XGraphicProvider;
|
|
|
|
using ::com::sun::star::uno::Sequence;
|
|
|
|
using ::com::sun::star::beans::PropertyValue;
|
|
|
|
using ::com::sun::star::graphic::XGraphic;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
|
|
|
|
namespace PropertyLineElement = ::com::sun::star::inspection::PropertyLineElement;
|
|
|
|
|
2014-09-23 11:20:40 +02:00
|
|
|
OBrowserLine::OBrowserLine( const OUString& _rEntryName, vcl::Window* pParent )
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
:m_sEntryName( _rEntryName )
|
2015-04-22 17:20:25 +01:00
|
|
|
,m_aFtTitle(VclPtr<FixedText>::Create(pParent))
|
2015-11-10 10:14:53 +01:00
|
|
|
,m_pControlWindow( nullptr )
|
|
|
|
,m_pBrowseButton(nullptr)
|
|
|
|
,m_pAdditionalBrowseButton( nullptr )
|
|
|
|
,m_pClickListener( nullptr )
|
2008-01-14 13:55:45 +00:00
|
|
|
,m_pTheParent(pParent)
|
|
|
|
,m_nNameWidth(0)
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
,m_nEnableFlags( 0xFFFF )
|
2008-01-14 13:55:45 +00:00
|
|
|
,m_bIndentTitle( false )
|
|
|
|
,m_bReadOnly( false )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-01-26 13:11:07 +02:00
|
|
|
m_aFtTitle->Show();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
OBrowserLine::~OBrowserLine()
|
|
|
|
{
|
2017-06-10 15:06:20 +01:00
|
|
|
implHideBrowseButton(true);
|
|
|
|
implHideBrowseButton(false);
|
2015-05-14 17:50:01 +01:00
|
|
|
m_aFtTitle.disposeAndClear();
|
2004-11-16 11:00:17 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2007-05-10 09:46:12 +00:00
|
|
|
void OBrowserLine::IndentTitle( bool _bIndent )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
|
|
|
if ( m_bIndentTitle != _bIndent )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
m_bIndentTitle = _bIndent;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-25 13:42:16 +01:00
|
|
|
void OBrowserLine::SetComponentHelpIds(const OString& _rHelpId)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
2010-06-04 13:46:22 +02:00
|
|
|
m_pControlWindow->SetHelpId( _rHelpId );
|
2004-11-16 11:00:17 +00:00
|
|
|
|
|
|
|
if ( m_pBrowseButton )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2010-06-04 13:46:22 +02:00
|
|
|
m_pBrowseButton->SetHelpId( _rHelpId );
|
2004-11-16 11:00:17 +00:00
|
|
|
|
|
|
|
if ( m_pAdditionalBrowseButton )
|
|
|
|
{
|
2010-06-04 13:46:22 +02:00
|
|
|
m_pAdditionalBrowseButton->SetHelpId( _rHelpId );
|
2004-11-16 11:00:17 +00:00
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void OBrowserLine::setControl( const Reference< XPropertyControl >& _rxControl )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_xControl = _rxControl;
|
2015-03-16 17:28:03 +00:00
|
|
|
m_pControlWindow = m_xControl.is() ? VCLUnoHelper::GetWindow( _rxControl->getControlWindow() ) : VclPtr<vcl::Window>();
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
DBG_ASSERT( m_pControlWindow, "OBrowserLine::setControl: setting NULL controls/windows is not allowed!" );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
|
|
|
{
|
|
|
|
m_pControlWindow->SetParent( m_pTheParent );
|
|
|
|
m_pControlWindow->Show();
|
|
|
|
}
|
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2014-09-23 11:20:40 +02:00
|
|
|
vcl::Window* OBrowserLine::GetRefWindow()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-01-26 13:11:07 +02:00
|
|
|
vcl::Window* pRefWindow = m_aFtTitle.get();
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2004-03-19 10:59:54 +00:00
|
|
|
if(m_pBrowseButton)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-06-08 16:25:04 +02:00
|
|
|
pRefWindow=static_cast<vcl::Window*>(m_pBrowseButton);
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
else if ( m_pControlWindow )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
pRefWindow = m_pControlWindow;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
return pRefWindow;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2015-05-22 13:48:09 +02:00
|
|
|
void OBrowserLine::SetTabOrder(vcl::Window* pRefWindow, ZOrderFlags nFlags )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-01-26 13:11:07 +02:00
|
|
|
m_aFtTitle->SetZOrder(pRefWindow,nFlags);
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
2015-05-22 13:48:09 +02:00
|
|
|
m_pControlWindow->SetZOrder( m_aFtTitle.get(), ZOrderFlags::Behind );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2014-02-23 13:18:13 +00:00
|
|
|
if ( m_pBrowseButton && m_pControlWindow )
|
2015-05-22 13:48:09 +02:00
|
|
|
m_pBrowseButton->SetZOrder( m_pControlWindow, ZOrderFlags::Behind );
|
2004-11-16 11:00:17 +00:00
|
|
|
|
2014-02-23 13:18:13 +00:00
|
|
|
if ( m_pAdditionalBrowseButton && m_pBrowseButton )
|
2015-05-22 13:48:09 +02:00
|
|
|
m_pAdditionalBrowseButton->SetZOrder( m_pBrowseButton, ZOrderFlags::Behind );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2014-04-30 11:46:15 +02:00
|
|
|
bool OBrowserLine::GrabFocus()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2014-04-30 11:46:15 +02:00
|
|
|
bool bRes=false;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow && m_pControlWindow->IsEnabled() )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_pControlWindow->GrabFocus();
|
2014-04-30 11:46:15 +02:00
|
|
|
bRes = true;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
else if ( m_pAdditionalBrowseButton && m_pAdditionalBrowseButton->IsEnabled() )
|
|
|
|
{
|
|
|
|
m_pAdditionalBrowseButton->GrabFocus();
|
2014-04-30 11:46:15 +02:00
|
|
|
bRes = true;
|
2004-11-16 11:00:17 +00:00
|
|
|
}
|
|
|
|
else if ( m_pBrowseButton && m_pBrowseButton->IsEnabled() )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-03-19 10:59:54 +00:00
|
|
|
m_pBrowseButton->GrabFocus();
|
2014-04-30 11:46:15 +02:00
|
|
|
bRes = true;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
return bRes;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
void OBrowserLine::SetPosSizePixel( Point _rPos, Size _rSize )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
m_aLinePos = _rPos;
|
|
|
|
m_aOutputSize = _rSize;
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2014-04-30 11:46:15 +02:00
|
|
|
void OBrowserLine::Show(bool bFlag)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-01-26 13:11:07 +02:00
|
|
|
m_aFtTitle->Show(bFlag);
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
|
|
|
m_pControlWindow->Show( bFlag );
|
2004-11-16 11:00:17 +00:00
|
|
|
if ( m_pBrowseButton )
|
|
|
|
m_pBrowseButton->Show( bFlag );
|
|
|
|
if ( m_pAdditionalBrowseButton )
|
|
|
|
m_pAdditionalBrowseButton->Show( bFlag );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2001-01-12 10:35:45 +00:00
|
|
|
void OBrowserLine::Hide()
|
|
|
|
{
|
2014-04-30 11:46:15 +02:00
|
|
|
Show(false);
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2014-04-30 11:46:15 +02:00
|
|
|
bool OBrowserLine::IsVisible()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-01-26 13:11:07 +02:00
|
|
|
return m_aFtTitle->IsVisible();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void OBrowserLine::impl_layoutComponents()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
Point aTitlePos( m_aLinePos.X(), m_aLinePos.Y() + 8 );
|
|
|
|
Size aTitleSize( m_nNameWidth - 3, m_aOutputSize.Height() );
|
2001-01-12 10:35:45 +00:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
if ( m_bIndentTitle )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2016-09-20 16:41:39 +02:00
|
|
|
Size aIndent( m_pTheParent->LogicToPixel( Size( 8, 0 ), MapUnit::MapAppFont ) );
|
2004-11-16 11:00:17 +00:00
|
|
|
aTitlePos.X() += aIndent.Width();
|
|
|
|
aTitleSize.Width() -= aIndent.Width();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2015-01-26 13:11:07 +02:00
|
|
|
m_aFtTitle->SetPosSizePixel( aTitlePos, aTitleSize );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
sal_Int32 nBrowseButtonSize = m_aOutputSize.Height() - 4;
|
2001-01-12 10:35:45 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
Point aControlPos( m_aLinePos.X() + m_nNameWidth, m_aLinePos.Y() + 2 );
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_pControlWindow->SetPosPixel( aControlPos );
|
2004-11-16 11:00:17 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
Size aControlSize( m_aOutputSize.Width() - 4 - m_nNameWidth - nBrowseButtonSize - 4, m_pControlWindow->GetSizePixel().Height() );
|
2004-11-16 11:00:17 +00:00
|
|
|
if ( m_pAdditionalBrowseButton )
|
|
|
|
aControlSize.Width() -= nBrowseButtonSize + 4;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
m_pControlWindow->SetSizePixel( aControlSize );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2004-03-19 10:59:54 +00:00
|
|
|
if ( m_pBrowseButton )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
Point aButtonPos( m_aOutputSize.Width() - 4 - nBrowseButtonSize, m_aLinePos.Y() + 2 );
|
|
|
|
Size aButtonSize( nBrowseButtonSize, nBrowseButtonSize );
|
|
|
|
m_pBrowseButton->SetPosSizePixel( aButtonPos, aButtonSize );
|
|
|
|
|
|
|
|
if ( m_pAdditionalBrowseButton )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
aButtonPos.X() -= nBrowseButtonSize + 4;
|
|
|
|
m_pAdditionalBrowseButton->SetPosSizePixel( aButtonPos, aButtonSize );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-06-17 16:45:36 +03:00
|
|
|
void OBrowserLine::SetTitle(const OUString& _rNewTitle )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2016-06-17 16:45:36 +03:00
|
|
|
if ( GetTitle() == _rNewTitle )
|
2005-03-10 16:00:01 +00:00
|
|
|
return;
|
2016-06-17 16:45:36 +03:00
|
|
|
m_aFtTitle->SetText( _rNewTitle );
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
2016-06-17 16:45:36 +03:00
|
|
|
m_pControlWindow->SetAccessibleName( _rNewTitle );
|
2004-09-08 16:50:06 +00:00
|
|
|
if ( m_pBrowseButton )
|
2016-06-17 16:45:36 +03:00
|
|
|
m_pBrowseButton->SetAccessibleName( _rNewTitle );
|
2002-11-05 08:56:59 +00:00
|
|
|
FullFillTitleString();
|
|
|
|
}
|
|
|
|
|
|
|
|
void OBrowserLine::FullFillTitleString()
|
|
|
|
{
|
|
|
|
if( m_pTheParent )
|
|
|
|
{
|
2015-01-26 13:11:07 +02:00
|
|
|
OUStringBuffer aText( m_aFtTitle->GetText() );
|
2013-06-23 15:47:36 +02:00
|
|
|
|
|
|
|
while( m_pTheParent->GetTextWidth( aText.toString() ) < m_nNameWidth )
|
|
|
|
aText.append("...........");
|
|
|
|
|
|
|
|
// for Issue 69452
|
2015-04-01 16:23:59 +02:00
|
|
|
if (AllSettings::GetLayoutRTL())
|
2013-06-23 15:47:36 +02:00
|
|
|
{
|
2017-06-23 10:22:25 +02:00
|
|
|
sal_Unicode const cRTL_mark = 0x200F;
|
2013-06-23 15:47:36 +02:00
|
|
|
aText.append( OUString(cRTL_mark) );
|
|
|
|
}
|
|
|
|
|
2015-01-26 13:11:07 +02:00
|
|
|
m_aFtTitle->SetText( aText.makeStringAndClear() );
|
2002-11-05 08:56:59 +00:00
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2013-08-14 10:00:48 +01:00
|
|
|
OUString OBrowserLine::GetTitle() const
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-01-26 13:11:07 +02:00
|
|
|
OUString sDisplayName = m_aFtTitle->GetText();
|
2007-06-12 04:37:26 +00:00
|
|
|
|
2011-11-22 23:40:24 +00:00
|
|
|
// for Issue 69452
|
2015-04-01 16:23:59 +02:00
|
|
|
if (AllSettings::GetLayoutRTL())
|
2011-11-22 23:40:24 +00:00
|
|
|
{
|
2017-06-23 10:22:25 +02:00
|
|
|
sal_Unicode const cRTL_mark = 0x200F;
|
2011-11-22 23:40:24 +00:00
|
|
|
sDisplayName = comphelper::string::stripEnd(sDisplayName, cRTL_mark);
|
|
|
|
}
|
2007-06-12 04:37:26 +00:00
|
|
|
|
2011-11-22 23:40:24 +00:00
|
|
|
sDisplayName = comphelper::string::stripEnd(sDisplayName, '.');
|
2007-06-12 04:37:26 +00:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
return sDisplayName;
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2007-05-10 09:46:12 +00:00
|
|
|
void OBrowserLine::SetReadOnly( bool _bReadOnly )
|
|
|
|
{
|
|
|
|
if ( m_bReadOnly != _bReadOnly )
|
|
|
|
{
|
|
|
|
m_bReadOnly = _bReadOnly;
|
|
|
|
implUpdateEnabledDisabled();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
namespace
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void implSetBitIfAffected( sal_uInt16& _nEnabledBits, sal_Int16 _nAffectedMask, sal_Int16 _nTestBit, bool _bSet )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( _nAffectedMask & _nTestBit )
|
2008-12-11 07:05:03 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( _bSet )
|
|
|
|
_nEnabledBits |= _nTestBit;
|
|
|
|
else
|
|
|
|
_nEnabledBits &= ~_nTestBit;
|
2008-12-11 07:05:03 +00:00
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
}
|
|
|
|
|
2014-09-23 11:20:40 +02:00
|
|
|
void implEnable( vcl::Window* _pWindow, sal_uInt16 _nEnabledBits, sal_uInt16 _nMatchBits )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
|
|
|
if ( _pWindow )
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
_pWindow->Enable( ( _nEnabledBits & _nMatchBits ) == _nMatchBits );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2007-05-10 09:46:12 +00:00
|
|
|
|
2014-09-23 11:20:40 +02:00
|
|
|
void implEnable( vcl::Window* _pWindow, bool _bEnable )
|
2007-05-10 09:46:12 +00:00
|
|
|
{
|
|
|
|
if ( _pWindow )
|
|
|
|
_pWindow->Enable( _bEnable );
|
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
void OBrowserLine::implUpdateEnabledDisabled()
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-01-26 13:11:07 +02:00
|
|
|
implEnable( m_aFtTitle.get(), m_nEnableFlags, PropertyLineElement::CompleteLine );
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_pControlWindow )
|
|
|
|
implEnable( m_pControlWindow, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::InputControl );
|
2007-05-10 09:46:12 +00:00
|
|
|
|
|
|
|
if ( m_bReadOnly )
|
|
|
|
{
|
|
|
|
implEnable( m_pBrowseButton, false );
|
|
|
|
implEnable( m_pAdditionalBrowseButton, false );
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
implEnable( m_pBrowseButton, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::PrimaryButton );
|
|
|
|
implEnable( m_pAdditionalBrowseButton, m_nEnableFlags, PropertyLineElement::CompleteLine | PropertyLineElement::SecondaryButton );
|
|
|
|
}
|
2004-11-16 11:00:17 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
void OBrowserLine::EnablePropertyLine( bool _bEnable )
|
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
implSetBitIfAffected( m_nEnableFlags, PropertyLineElement::CompleteLine, PropertyLineElement::CompleteLine, _bEnable );
|
2004-11-16 11:00:17 +00:00
|
|
|
implUpdateEnabledDisabled();
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
void OBrowserLine::EnablePropertyControls( sal_Int16 _nControls, bool _bEnable )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::InputControl, _bEnable );
|
|
|
|
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::PrimaryButton, _bEnable );
|
|
|
|
implSetBitIfAffected( m_nEnableFlags, _nControls, PropertyLineElement::SecondaryButton, _bEnable );
|
2004-11-16 11:00:17 +00:00
|
|
|
implUpdateEnabledDisabled();
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2007-08-03 12:52:21 +00:00
|
|
|
PushButton& OBrowserLine::impl_ensureButton( bool _bPrimary )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
2015-03-09 14:29:30 +02:00
|
|
|
VclPtr<PushButton>& rpButton = _bPrimary ? m_pBrowseButton : m_pAdditionalBrowseButton;
|
2004-11-16 11:00:17 +00:00
|
|
|
|
|
|
|
if ( !rpButton )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-04-22 17:20:25 +01:00
|
|
|
rpButton = VclPtr<PushButton>::Create( m_pTheParent, WB_NOPOINTERFOCUS );
|
2004-11-16 11:00:17 +00:00
|
|
|
rpButton->SetGetFocusHdl( LINK( this, OBrowserLine, OnButtonFocus ) );
|
|
|
|
rpButton->SetClickHdl( LINK( this, OBrowserLine, OnButtonClicked ) );
|
2015-11-06 09:35:47 +01:00
|
|
|
rpButton->SetText("...");
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2007-08-03 12:52:21 +00:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
rpButton->Show();
|
|
|
|
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2007-08-03 12:52:21 +00:00
|
|
|
|
|
|
|
return *rpButton;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-11-08 11:10:50 +02:00
|
|
|
void OBrowserLine::ShowBrowseButton( const OUString& _rImageURL, bool _bPrimary )
|
2007-08-03 12:52:21 +00:00
|
|
|
{
|
2016-11-08 11:10:50 +02:00
|
|
|
PushButton& rButton( impl_ensureButton( _bPrimary ) );
|
|
|
|
|
|
|
|
OSL_PRECOND( !_rImageURL.isEmpty(), "OBrowserLine::ShowBrowseButton: use the other version if you don't have an image!" );
|
|
|
|
Image aImage;
|
2007-08-03 12:52:21 +00:00
|
|
|
try
|
|
|
|
{
|
2012-05-26 13:53:19 +02:00
|
|
|
Reference< XComponentContext > xContext( ::comphelper::getProcessComponentContext() );
|
|
|
|
Reference< XGraphicProvider > xGraphicProvider( GraphicProvider::create(xContext) );
|
2007-08-03 12:52:21 +00:00
|
|
|
|
|
|
|
Sequence< PropertyValue > aMediaProperties(1);
|
2013-11-15 11:05:19 +02:00
|
|
|
aMediaProperties[0].Name = "URL";
|
2007-08-03 12:52:21 +00:00
|
|
|
aMediaProperties[0].Value <<= _rImageURL;
|
|
|
|
|
|
|
|
Reference< XGraphic > xGraphic( xGraphicProvider->queryGraphic( aMediaProperties ), UNO_QUERY_THROW );
|
2016-11-08 11:10:50 +02:00
|
|
|
aImage = Image( xGraphic );
|
2007-08-03 12:52:21 +00:00
|
|
|
}
|
|
|
|
catch( const Exception& )
|
|
|
|
{
|
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
|
|
|
}
|
|
|
|
|
2010-11-13 00:33:43 -08:00
|
|
|
rButton.SetModeImage( aImage );
|
2017-06-10 15:06:20 +01:00
|
|
|
}
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2014-04-30 11:46:15 +02:00
|
|
|
void OBrowserLine::ShowBrowseButton( const Image& _rImage, bool _bPrimary )
|
2007-08-03 12:52:21 +00:00
|
|
|
{
|
|
|
|
PushButton& rButton( impl_ensureButton( _bPrimary ) );
|
|
|
|
if ( !!_rImage )
|
|
|
|
rButton.SetModeImage( _rImage );
|
|
|
|
}
|
|
|
|
|
2014-04-30 11:46:15 +02:00
|
|
|
void OBrowserLine::ShowBrowseButton( bool _bPrimary )
|
2007-08-03 12:52:21 +00:00
|
|
|
{
|
|
|
|
impl_ensureButton( _bPrimary );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2017-06-10 15:06:20 +01:00
|
|
|
void OBrowserLine::implHideBrowseButton(bool _bPrimary)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2015-03-09 14:29:30 +02:00
|
|
|
VclPtr<PushButton>& rpButton = _bPrimary ? m_pBrowseButton : m_pAdditionalBrowseButton;
|
2004-11-16 11:00:17 +00:00
|
|
|
|
|
|
|
if ( rpButton )
|
|
|
|
{
|
|
|
|
rpButton->Hide();
|
2015-04-10 10:44:13 +01:00
|
|
|
rpButton.disposeAndClear();
|
2004-11-16 11:00:17 +00:00
|
|
|
}
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2017-06-10 15:06:20 +01:00
|
|
|
void OBrowserLine::HideBrowseButton(bool _bPrimary)
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2017-06-10 15:06:20 +01:00
|
|
|
implHideBrowseButton(_bPrimary);
|
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void OBrowserLine::SetTitleWidth(sal_uInt16 nWidth)
|
|
|
|
{
|
|
|
|
if (m_nNameWidth != nWidth+10)
|
|
|
|
{
|
|
|
|
m_nNameWidth = nWidth+10;
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
impl_layoutComponents();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
2002-11-05 08:56:59 +00:00
|
|
|
FullFillTitleString();
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2004-11-16 11:00:17 +00:00
|
|
|
void OBrowserLine::SetClickListener( IButtonClickListener* _pListener )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
2004-11-16 11:00:17 +00:00
|
|
|
m_pClickListener = _pListener;
|
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-10-05 07:56:12 +02:00
|
|
|
IMPL_LINK( OBrowserLine, OnButtonClicked, Button*, _pButton, void )
|
2004-11-16 11:00:17 +00:00
|
|
|
{
|
|
|
|
if ( m_pClickListener )
|
|
|
|
m_pClickListener->buttonClicked( this, _pButton == m_pBrowseButton );
|
2001-01-12 10:35:45 +00:00
|
|
|
}
|
|
|
|
|
2014-02-22 21:20:15 +01:00
|
|
|
|
2016-10-05 07:56:12 +02:00
|
|
|
IMPL_LINK_NOARG( OBrowserLine, OnButtonFocus, Control&, void )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
if ( m_xControl.is() )
|
2001-01-12 10:35:45 +00:00
|
|
|
{
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
try
|
|
|
|
{
|
|
|
|
Reference< XPropertyControlContext > xContext( m_xControl->getControlContext(), UNO_QUERY_THROW );
|
|
|
|
xContext->focusGained( m_xControl );
|
|
|
|
}
|
2008-01-14 13:55:45 +00:00
|
|
|
catch( const Exception& )
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
{
|
2008-01-14 13:55:45 +00:00
|
|
|
DBG_UNHANDLED_EXCEPTION();
|
INTEGRATION: CWS pbrwuno (1.9.96); FILE MERGED
2005/10/11 13:28:40 fs 1.9.96.6: #i53095# phase 3:
introduced XPropertyHandler and XObjectInspectorUI
same open issues as in previous phase
(plus probably some more, since not everything is tested, yet :-\)
2005/10/05 06:48:43 fs 1.9.96.5: RESYNC: (1.9-1.10); FILE MERGED
2005/09/05 07:41:46 fs 1.9.96.4: #i53095# phase 3, part 1: introduced XPropertyControl and relatives,
describing one control in the ObjectInspector, responsible for one
property
known issues:
- rebuildPropertyUI can cause problems now: If the user clicks into
the control for property A, which causes property B to be committed,
which causes the UI for property A to be rebuilt, then this will
crash currently. Reason: rebuildPropertyUI now synchronously replaces
the VCL-Window of the rebuilt control, which is exactly the one
which is still in some MouseButtonDown-handler.
possible solutions:
- see if rebuiltPropertyUI can be obsoleted - handlers should be able
to just obtain the XPropertyControl from the PropertyUI, and
re-initialize the control. Shouldn't they?`
- make one of the steps in the chain (mouse-click, handler-call,
rebuildPropertyUI-callback) asynchronous.
2005/08/31 08:28:50 fs 1.9.96.3: #i53095# get rid of Set/GetPropertyName at the IBrowserControl
2005/08/12 16:30:06 fs 1.9.96.2: - more fine-grained control in the IPropertyBrowserUI which elements
to enable or disable
- moved designing the SQL command into a dedicated handler
- some more reactions on actuating properties move to dedicated handlers
- *nearly* completed implementation of the "composed browser UI", which
collects and combines UI change requests (IPropertyBrowserUI)
(still missing: proper auto-firing)
2005/08/09 13:59:54 fs 1.9.96.1: #i53095# phase 1:
- don't use strings to transver values between controls and introspectee, but Anys
- first version of a dedicated property handler for form-component-related properties
(not yet completed)
known regressions over previous phase:
- handlers for events not yet implemented, thus some assertions
- click handlers for form-component-related properties do not yet work,
thus the browse buttons mostly do not work
2006-03-14 10:17:00 +00:00
|
|
|
}
|
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
|
|
|
|
2010-10-12 15:57:08 +02:00
|
|
|
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
|