# Understanding Transitional VCL Lifecycle ## How it used to look All VCL classes were explicitly lifecycle managed; so you would do: ``` Dialog aDialog(...); // old - on stack allocation aDialog.Execute(...); ``` or: ``` Dialog *pDialog = new Dialog(...); // old - manual heap allocation pDialog->Execute(...); delete pDialog; ``` or: ``` std::shared_ptr xDialog(new pDialog()); // old xDialog->Execute(...); // depending who shared the ptr this would be freed sometime ``` In several cases this lead to rather unpleasant code, when various `shared_ptr` wrappers were used, the lifecycle was far less than obvious. Where controls were wrapped by other ref-counted classes - such as UNO interfaces, which were also used by native Window pointers, the lifecycle became extremely opaque. In addition VCL had significant issues with re-enterancy and event emission - adding various means such as DogTags to try to detect destruction of a window between calls: ``` ImplDelData aDogTag( this ); // 'orrible old code Show( true, ShowFlags::NoActivate ); if( !aDogTag.IsDead() ) // did 'this' go invalid yet ? Update(); ``` Unfortunately use of such protection is/was ad-hoc, and far from uniform, despite the prevalence of such potential problems. When a lifecycle problem was hit, typically it would take the form of accessing memory that had been freed, and contained garbage due to lingering pointers to freed objects. ## Where we are now To fix this situation we now have a `VclPtr` - which is a smart reference-counting pointer (`include/vcl/vclptr.hxx`) which is designed to look and behave -very- much like a normal pointer to reduce code-thrash. `VclPtr` is used to wrap all `OutputDevice` derived classes thus: ``` VclPtr pDialog( new Dialog( ... ), SAL_NO_ACQUIRE ); ... pDialog.disposeAndClear(); ``` However - while the `VclPtr` reference count controls the lifecycle of the Dialog object, it is necessary to be able to break reference count cycles. These are extremely common in widget hierarchies as each widget holds (smart) pointers to its parents and also its children. Thus - all previous `delete` calls are replaced with `dispose` method calls: ## What is dispose ? Dispose is defined to be a method that releases all references that an object holds - thus allowing their underlying resources to be released. However - in this specific case it also releases all backing graphical resources. In practical terms, all destructor functionality has been moved into `dispose` methods, in order to provide a minimal initial behavioral change. As such a `VclPtr` can have three states: ``` VclPtr pButton; ... assert (pButton == nullptr || !pButton); // null assert (pButton && !pButton->isDisposed()); // alive assert (pButton && pButton->isDisposed()); // disposed ``` ## `ScopedVclPtr` - making disposes easier While replacing existing code with new, it can be a bit tiresome to have to manually add `disposeAndClear()` calls to `VclPtr<>` instances. Luckily it is easy to avoid that with a `ScopedVclPtr` which does this for you when it goes out of scope. ## One extra gotcha - an initial reference-count of 1 In the normal world of love and sanity, eg. creating UNO objects, the objects start with a ref-count of zero. Thus the first reference is always taken after construction by the surrounding smart pointer. Unfortunately, the existing VCL code is somewhat tortured, and does a lot of reference and de-reference action on the class -during- construction. This forces us to construct with a reference of 1 - and to hand that into the initial smart pointer with a `SAL_NO_ACQUIRE`. To make this easier, we have `Instance` template wrappers that make this apparently easier, by constructing the pointer for you. ### How does my familiar code change ? Lets tweak the exemplary code above to fit the new model: ``` - Dialog aDialog(... dialog params ... ); - aDialog.Execute(...); + ScopedVclPtrInstance pDialog(... dialog params ... ); + pDialog->Execute(...); // VclPtr behaves much like a pointer ``` or: ``` - Dialog *pDialog = new Dialog(... dialog params ...); + VclPtrInstance pDialog(... dialog params ...); pDialog->Execute(...); - delete pDialog; + pDialog.disposeAndClear(); // done manually - replaces a delete ``` or: ``` - std::shared_ptr xDialog(new Dialog(...)); + ScopedVclPtrInstance xDialog(...); xDialog->Execute(...); + // depending how shared_ptr was shared perhaps + // someone else gets a VclPtr to xDialog ``` or: ``` - VirtualDevice aDev; + ScopedVclPtrInstance pDev; ``` Other things that are changed are these: ``` - pButton = new PushButton(NULL); + pButton = VclPtr::Create(nullptr); ... - vcl::Window *pWindow = new PushButton(NULL); + VclPtr pWindow; + pWindow.reset(VclPtr::Create(nullptr)); ``` ### Why are these `disposeOnce` calls in destructors? This is an interim measure while we are migrating, such that it is possible to delete an object conventionally and ensure that its dispose method gets called. In the 'end' we would instead assert that a Window has been disposed in its destructor, and elide these calls. As the object's vtable is altered as we go down the destruction process, and we want to call the correct dispose methods we need this `disposeOnce();` call for the interim in every destructor. This is enforced by a clang plugin. The plus side of disposeOnce is that the mechanics behind it ensure that a `dispose()` method is only called a single time, simplifying their implementation. ### Who owns & disposes what? Window sub-classes tend to create their widgets in one of two ways and often both. 1. Derive from `VclBuilderContainer`. The `VclBuilder` then owns many of the sub-windows, which are fetched by a `get` method into local variables often in constructors eg. ``` VclPtr mpButton; // in the class , get(mpButton, "buttonName") // in the constructor mpButton.clear(); // in dispose. ``` We only clear, not `disposeAndClear()` in our dispose method for this case, since the `VclBuilder` / Container truly owns this Window, and needs to dispose its hierarchy in the right order - first children then parents. 2. Explicitly allocated Windows. These are often created and managed by custom widgets: ``` VclPtr mpComplex; // in the class , mpComplex( VclPtr::Create( this ) ) // constructor mpComplex.disposeAndClear(); // in dispose ``` ie. an owner has to dispose things they explicitly allocate. In order to ensure that the VclBuilderConstructor sub-classes have their Windows disposed at the correct time there is a `disposeBuilder();` method - that should be added -only- to the class immediately deriving from `VclBuilderContainer`'s dispose. ### What remains to be done? * Expand the `VclPtr` pattern to many other less than safe VCL types. * create factory functions for `VclPtr<>` types and privatize their constructors. * Pass `const VclPtr<> &` instead of pointers everywhere + add `explicit` keywords to VclPtr constructors to accelerate compilation etc. * Cleanup common existing methods such that they continue to work post-dispose. * Dispose functions should be audited to: + not leave dangling pointsr + shrink them - some work should incrementally migrate back to destructors. * `VclBuilder` + ideally should keep a reference to pointers assigned in `get()` calls - to avoid needing explicit `clear` code in destructors. ## FAQ / debugging hints ### Compile with dbgutil This is by far the best way to turn on debugging and assertions that help you find problems. In particular there are a few that are really helpful: ``` vcl/source/window/window.cxx (Window::dispose) "Window ( N4sfx27sidebar20SidebarDockingWindowE (Properties)) ^^^ class name window title ^^^ with live children destroyed: N4sfx27sidebar6TabBarE () N4sfx27sidebar4DeckE () 10FixedImage ()" ``` You can de-mangle these names if you can't read them thus: ``` $ c++filt -t N4sfx27sidebar20SidebarDockingWindowE sfx2::sidebar::SidebarDockingWindow ``` In the above case - it is clear that the children have not been disposed before their parents. As an aside, having a dispose chain separate from destructors allows us to emit real type names for parents here. To fix this, we will need to get the dispose ordering right, occasionally in the conversion we re-ordered destruction, or omitted a `disposeAndClear()` in a `::dispose()` method. - If you see this, check the order of `disposeAndClear()` in the `sfx2::Sidebar::SidebarDockingWindow::dispose()` method - also worth `git grep`ing for `new sfx::sidebar::TabBar` to see where those children were added. ### Check what it used to do While a ton of effort has been put into ensuring that the new lifecycle code is the functional equivalent of the old code, the code was created by humans. If you identify an area where something asserts or crashes here are a few helpful heuristics: * Read the `git log -u -- path/to/file.cxx` ### Is the order of destruction different? In the past many things were destructed (in reverse order of declaration in the class) without explicit code. Some of these may be important to do explicitly at the end of the destructor. eg. having a `Idle` or `Timer` as a member, may now need an explicit `.Stop()` and/or protection from running on a disposed Window in its callback. ### Is it `clear` not `disposeAndClear`? sometimes we get this wrong. If the code previously used to use `delete pFoo;` it should now read `pFoo->disposeAndClear();`. Conversely if it didn't delete it, it should be `clear()` it is by far the best to leave disposing to the `VclBuilder` where possible. In simple cases, if we allocate the widget with `VclPtrInstance` or `VclPtr::Create` - then we need to `disposeAndClear` it too. ### Event / focus / notification ordering In the old world, a large amount of work was done in the `~Window` destructor that is now done in `Window::dispose`. Since those Windows were in the process of being destroyed themselves, their vtables were adjusted to only invoke Window methods. In the new world, sub-classed methods such as `PreNotify`, `GetFocus`, `LoseFocus` and others are invoked all down the inheritance chain from children to parent, during dispose. The easiest way to fix these is to just ensure that these cleanup methods, especially LoseFocus, continue to work even on disposed Window sub-class instances. ### It crashes with some invalid memory... Assuming that the invalid memory is a Window sub-class itself, then almost certainly there is some cockup in the reference-counting; eg. if you hit an `OutputDevice::release` assert on `mnRefCount` - then almost certainly you have a Window that has already been destroyed. This can easily happen via this sort of pattern: ``` Dialog *pDlg = VclPtr(nullptr /* parent */); // by here the pDlg quite probably points to free'd memory... ``` It is necessary in these cases to ensure that the `*pDlg` is a `VclPtr` instead. ### It crashes with some invalid memory #2... Often a `::dispose` method will free some `pImpl` member, but not `NULL` it; and (cf. above) we can now get various `virtual` methods called post-dispose; so: a) `delete pImpl; pImpl = NULL; // in the destructor` b) `if (pImpl && ...) // in the subsequently called method` alctiledrendering LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/sw/inc/unoframe.hxx
AgeCommit message (Collapse)Author
2019-01-16SwXOLEListener: not SwClient/ModifyBjoern Michaelsen
Change-Id: Ie27432549e835622ab8480acfb3ed613aef623ab Reviewed-on: https://gerrit.libreoffice.org/66411 Tested-by: Jenkins Reviewed-by: Björn Michaelsen <bjoern.michaelsen@libreoffice.org>
2018-12-19tdf#99631 DOCX import: keep zoom of embedded XLSXLászló Németh
OLE objects by importing their VisibleArea settings This also reverts commit 5c1a6c9adb5ccfbb869a0a7ac730d8860a1bf405 "tdf#99631 DOCX import: set 1:1 scale in embedded XLSX". Change-Id: I73dc945c86d0200e72767810b2ff39f233729080 Reviewed-on: https://gerrit.libreoffice.org/65343 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2018-04-25sw: fix remaining IWYU warnings in inc/*.hxxMiklos Vajna
Also check for not needed forward declarations. Change-Id: I92759f3f40d9458fd192665b39b87a78d8b97e5a Reviewed-on: https://gerrit.libreoffice.org/53418 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-04-17remove no longer necessary operator new/delete overridesNoel Grandin
and use "using" statements for the places where the overrides were resolving ambiguities Change-Id: Icb1d1a41f19e00f28a19947aa2c40bd5778fff94 Reviewed-on: https://gerrit.libreoffice.org/52993 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-04-05sw: fix some IWYU warningsMiklos Vajna
Change-Id: I0c1d05b3f842a8d607a934f6954bcf2175d0d419 Reviewed-on: https://gerrit.libreoffice.org/52407 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-02-15sw: replace DELETEZ with unique_ptr in SwXFrameMichael Stahl
Change-Id: I93043bd17a685a82f9365c3eeb27d4288291e2f3 Reviewed-on: https://gerrit.libreoffice.org/49731 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2018-02-01sw: convert DELETEZ to std::unique_ptr in SwXFrameMichael Stahl
Change-Id: I1aa9d0fc8712773ea87ea8419c384f6f23258387
2017-12-07loplugin:salcall handle static methodsNoel Grandin
Change-Id: Id6820abec4b8ca8bee26d62b333fd30b42a14aec Reviewed-on: https://gerrit.libreoffice.org/46007 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-10-23loplugin:includeform: swStephan Bergmann
Change-Id: Ifc3c4c31a31ee7189eeab6f1af30b94d64f2f92a
2017-10-23loplugin:finalclasses in swNoel Grandin
Change-Id: I3b1d689d5eb800a36466376bca735dd31fe4567c Reviewed-on: https://gerrit.libreoffice.org/43639 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-08tdf#108545 show an icon (DOCX inside DOCX)Szymon Kłos
If DrawAspect is equal "Icon", show an icon not document preview Document is opened in the separate window, not in-place. Change-Id: I3a8d81e7340b29d247f8ac440c06b0420bb65644 Reviewed-on: https://gerrit.libreoffice.org/39440 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
2017-01-26Remove dynamic exception specificationsStephan Bergmann
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html> "Dynamic Exception Specifications" for details. Most changes have been done automatically by the rewriting loplugin:dynexcspec (after enabling the rewriting mode, to be committed shortly). The way it only removes exception specs from declarations if it also sees a definition, it identified some dead declarations-w/o-definitions (that have been removed manually) and some cases where a definition appeared in multiple include files (which have also been cleaned up manually). There's also been cases of macro paramters (that were used to abstract over exception specs) that have become unused now (and been removed). Furthermore, some code needed to be cleaned up manually (avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no configurations available that would actually build that code. Missing @throws documentation has not been applied in such manual clean-up. Change-Id: I3408691256c9b0c12bc5332de976743626e13960 Reviewed-on: https://gerrit.libreoffice.org/33574 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-19New loplugin:dynexcspec: Add @throws documentation, swStephan Bergmann
Change-Id: I2da2ce4cd247e7b9f973150917b4ee7bd7a0e0c4
2016-11-29sw: indentation fixesMiklos Vajna
Change-Id: I1b48b7aca377075c3575c25e104e2c617dbdfd66
2016-10-28update unnecessaryoverride plugin to find pure forwarding methodsNoel Grandin
which can be replaced with using declarations. Is there a more efficient way to code the search? Seems to slow the build down a little. Change-Id: I08cda21fa70dce6572e1acc71bf5e6df36bb951f Reviewed-on: https://gerrit.libreoffice.org/30157 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-10-27loplugin:expandablemethods in swNoel Grandin
Change-Id: Ibc9edc28f4041235ab30c026bd3774bd74b7e960 Reviewed-on: https://gerrit.libreoffice.org/30287 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-09-13loplugin:override: No more need for the "MSVC dtor override" workaroundStephan Bergmann
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2016-07-15sw: indentation fixesMiklos Vajna
Change-Id: I6cdc7cff7c45e58c9b684ff53a8dd84af7cf0c83
2016-07-07loplugin:passstuffbyref also for {css::uno,rtl}::ReferenceStephan Bergmann
Change-Id: I7e7cdfa5efaf18bb47d40947d4e1d91a2c9b5a57
2016-06-21sw: replace pointless XComponent and XTextContent overridesMichael Stahl
... from SwXTextGraphicObject and SwXTextEmbeddedObject. Change-Id: I22c2937617b84262c124d2504a8f9d889895005b
2016-06-21sw: use ImplInheritanceHelper for SwXTextGraphicObjectMichael Stahl
... and SwXTextEmbeddedObjectBaseClass, and get rid of pointless manual overriding of XInterface and XTypeProvider. Change-Id: I6695d825b5caba08aca9764eb3052eab77ee6fdb
2015-11-115th step to remove tools/rtti.hxxOliver Specht
tools/rtti.hxx removed completed the interface of some Sdr.* Items and removed pseudo items Change-Id: I0cdcd01494be35b97a27d5985aa908affa96048a Reviewed-on: https://gerrit.libreoffice.org/19837 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Oliver Specht <oliver.specht@cib.de>
2015-11-06com::sun::star->css in sw/incNoel Grandin
Change-Id: I6ffdb1deaa32156c65f997a1a1056928b7cd863d Reviewed-on: https://gerrit.libreoffice.org/19803 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2015-10-12Replace "SAL_OVERRIDE" with "override" in LIBO_INTERNAL_ONLY codeStephan Bergmann
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
2015-10-06 tdf#94559: 4th step to remove rtti.hxxOliver Specht
replaced use of PTR_CAST, IS_TYPE, ISA in idl, editeng, sc, sd, sw, sfx2, sot, starmath Change-Id: I4a5bba4fdc4829099618c09b690c83f876a3d653 Reviewed-on: https://gerrit.libreoffice.org/19132 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Oliver Specht <oliver.specht@cib.de>
2015-05-20bin/rename-sw-abbreviations.shlibreoffice-5-0-branch-pointChristian Lohmaier
renames the most annoying abbreviations in Writer (and partially in the shared code too). Change-Id: I9a62759138126c1537cc5c985ba05cf54d6132d9
2015-04-15remove unnecessary use of void in function declarationsNoel Grandin
ie. void f(void); becomes void f(); I used the following command to make the changes: git grep -lP '\(\s*void\s*\)' -- *.cxx \ | xargs perl -pi -w -e 's/(\w+)\s*\(\s*void\s*\)/$1\(\)/g;' and ran it for both .cxx and .hxx files. Change-Id: I314a1b56e9c14d10726e32841736b0ad5eef8ddd
2015-04-06sw: use variadic cppu::WeakImplHelperMiklos Vajna
Change-Id: I2c03ffad8d935bad126c19a8647c924af5a9bce5 Reviewed-on: https://gerrit.libreoffice.org/15174 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2015-03-28have a Reference instead of SwClient meddlingBjoern Michaelsen
Change-Id: I484061f124e5eaadd6e08a17f91dd18faf30b871
2014-11-14loplugin: cstylecastNoel Grandin
Change-Id: I7235a67e85c10ec9fefe7f718cda18f633cda97a
2014-10-25coverity#1249466 Uncaught exceptionCaolán McNamara
Change-Id: I58f646ed921d26c5a7d512279723e9d141886218
2014-10-17coverity#1247631 Uncaught exceptionCaolán McNamara
Change-Id: I92e59b18cef0828040c88ffbde150de6bb0d16a5
2014-09-23loplugin: cstylecast, update PTR_CAST macro to use static_castNoel Grandin
I introduce a template method into the PTR_CAST machinery to maintain constness. There is now a FIXME in sd/../docshell.cxx because I needed to use a dynamic_cast there to work around the games it appears to be playing with OLE in-place activation. Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, dropping the GCC-extension, unnecessary use of typeof from tools/rtti.hxx Change-Id: Iba5ace1aa27e02b34fcc91af1e658c43371afd03
2014-08-20make SwXFrame derived constructors privateMichael Stahl
... so that new instances have to be created by the factory functions. Change-Id: I643a154609b1a277d5cbc22d739ef8e357028f56
2014-08-20i#105557: thread-safe caching of SwXFrame instancesMichael Stahl
Replace SwXFrames::GetObject() with factory functions that use the WeakReference SwFrmFmt::m_wXObject to cache the instance in a thread-safe way. Change-Id: If56e4d7f95cb4f2e112139f228fb832ae9bf7d76
2014-07-01Related: #i124638# Second step of DrawingLayer FillAttributes...Armin Le Grand
for Writer objects, now added support for Paragraph and PageStyle (including Header and Footer) for direct attributes and style attributes (cherry picked from commit cc25c58f7052827bfebdc9fbeec668c8fa29ed1b) Conflicts: cui/source/factory/dlgfact.cxx cui/source/factory/dlgfact.hxx cui/source/inc/bbdlg.hxx cui/source/inc/cuires.hrc cui/source/tabpages/bbdlg.cxx cui/source/tabpages/bbdlg.src cui/source/tabpages/page.cxx cui/source/tabpages/tparea.cxx include/svx/pagectrl.hxx include/svx/svxdlg.hxx include/svx/svxids.hrc include/xmloff/PageMasterStyleMap.hxx include/xmloff/prstylei.hxx include/xmloff/txtprmap.hxx svx/Package_inc.mk svx/inc/svx/hdft.hxx svx/source/dialog/hdft.cxx svx/source/dialog/pagectrl.cxx svx/source/tbxctrls/tbxcolorupdate.cxx svx/source/unodraw/unobrushitemhelper.cxx sw/Library_sw.mk sw/inc/fillattributes.hxx sw/inc/format.hxx sw/inc/frmatr.hxx sw/inc/frmfmt.hxx sw/inc/hintids.hxx sw/inc/hints.hxx sw/inc/ndtxt.hxx sw/inc/node.hxx sw/inc/swunohelper.hxx sw/inc/unobrushitemhelper.hxx sw/inc/unoprnms.hxx sw/source/core/attr/format.cxx sw/source/core/attr/hints.cxx sw/source/core/doc/docdesc.cxx sw/source/core/doc/docdraw.cxx sw/source/core/doc/docfmt.cxx sw/source/core/doc/docnew.cxx sw/source/core/doc/docredln.cxx sw/source/core/doc/poolfmt.cxx sw/source/core/doc/visiturl.cxx sw/source/core/docnode/node.cxx sw/source/core/inc/frame.hxx sw/source/core/inc/frmtool.hxx sw/source/core/inc/rolbck.hxx sw/source/core/layout/atrfrm.cxx sw/source/core/layout/fillattributes.cxx sw/source/core/layout/findfrm.cxx sw/source/core/layout/paintfrm.cxx sw/source/core/txtnode/ndtxt.cxx sw/source/core/txtnode/thints.cxx sw/source/core/txtnode/txtedt.cxx sw/source/core/undo/rolbck.cxx sw/source/core/unocore/swunohelper.cxx sw/source/core/unocore/unoframe.cxx sw/source/core/unocore/unomap.cxx sw/source/core/unocore/unoparagraph.cxx sw/source/core/unocore/unoprnms.cxx sw/source/core/unocore/unostyle.cxx sw/source/ui/chrdlg/paradlg.src sw/source/ui/chrdlg/pardlg.cxx sw/source/ui/fmtui/tmpdlg.cxx sw/source/ui/fmtui/tmpdlg.src sw/source/uibase/app/docst.cxx sw/source/uibase/app/docstyle.cxx sw/source/uibase/frmdlg/colex.cxx sw/source/uibase/shells/basesh.cxx sw/source/uibase/shells/textsh1.cxx sw/source/uibase/uiview/viewstat.cxx sw/source/uibase/utlui/uitool.cxx xmloff/inc/PageMasterImportContext.hxx xmloff/inc/xmloff/XMLShapeStyleContext.hxx xmloff/source/draw/XMLShapeStyleContext.cxx xmloff/source/draw/sdpropls.hxx xmloff/source/style/PageMasterExportPropMapper.cxx xmloff/source/style/PageMasterImportContext.cxx xmloff/source/style/PageMasterPropHdlFactory.cxx xmloff/source/style/PageMasterStyleMap.cxx xmloff/source/style/prstylei.cxx xmloff/source/text/txtexppr.cxx xmloff/source/text/txtprhdl.cxx xmloff/source/text/txtprmap.cxx xmloff/source/text/txtstyli.cxx Conflicts: svx/source/dialog/hdft.cxx sw/source/core/doc/visiturl.cxx sw/source/core/txtnode/thints.cxx sw/source/core/txtnode/txtatr2.cxx sw/source/core/unocore/unostyle.cxx Change-Id: I7e8779db6c0cbd1e242b63eab888f468f2de509a