Files
libreoffice/sw/inc/docary.hxx

404 lines
15 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
re-base on ALv2 code. Includes: Patches contributed by Oliver-Rainer Wittmann sw34bf06: #i117783# - Writer's implementation of XPagePrintable - apply print settings to new printing routines http://svn.apache.org/viewvc?view=revision&revision=1172115 sw34bf06: #o12311627# use <rtl_random> methods to create unique ids for list styles and list ids http://svn.apache.org/viewvc?view=revision&revision=1172112 sw34bf06 #i114725#,#i115828# - method <SwDoc::ClearDoc()> - clear list structures completely http://svn.apache.org/viewvc?view=revision&revision=1172122 i#118572 - remove ui string and help content regarding usage of Java Mail in Writer's Mail Merge as Java Mail is not used. http://svn.apache.org/viewvc?view=revision&revision=1197035 Patches contributed by Mathias Bauer cws mba34issues01: #i117718#: provide filter name in case storage of medium does not allow to detect one http://svn.apache.org/viewvc?view=revision&revision=1172350 cws mba34issues01: #i117721#: directly provide parameters retrieved from SfxMedium http://svn.apache.org/viewvc?view=revision&revision=1172353 gnumake4 work variously http://svn.apache.org/viewvc?view=revision&revision=1394707 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 cws mba34issues01: #i117723#: convert assertion into trace http://svn.apache.org/viewvc?view=revision&revision=1172355 cws mba34issues01: #i117699#: keep layout alive until swdoc dies http://svn.apache.org/viewvc?view=revision&revision=1172362 cws mba34issues01: #i117943#: missing color attributes in RTF clipboard http://svn.apache.org/viewvc?view=revision&revision=1172363 Patch contributed by Henning Brinkmann imported patch i#103878 http://svn.apache.org/viewvc?view=revision&revision=1172109 Patches contributed by Michael Stahl sw34bf06: #i117955#: WW8 export: disable storing of section breaks in endnotes http://svn.apache.org/viewvc?view=revision&revision=1172119 Patch contributed by imacat Fixed the Asian language work count. http://svn.apache.org/viewvc?view=revision&revision=1241345 Patch contributed by Pedro Giffuni i#20878 - Add comment with BZ issue for reference. http://svn.apache.org/viewvc?view=revision&revision=1244517 Patch contributed by Andre Fischer Do not add targets for junit tests when junit is disabled. http://svn.apache.org/viewvc?view=revision&revision=1241508 add writerperfect dependency.
2011-03-31 10:05:04 +02:00
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following license notice:
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed
* with this work for additional information regarding copyright
* ownership. The ASF licenses this file to you under the Apache
* License, Version 2.0 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
#ifndef INCLUDED_SW_INC_DOCARY_HXX
#define INCLUDED_SW_INC_DOCARY_HXX
2000-09-18 16:15:01 +00:00
#include <vector>
#include <type_traits>
#include <o3tl/sorted_vector.hxx>
#include <boost/multi_index_container.hpp>
#include <boost/multi_index/composite_key.hpp>
#include <boost/multi_index/identity.hpp>
#include <boost/multi_index/mem_fun.hpp>
#include <boost/multi_index/ordered_index.hpp>
#include <boost/multi_index/random_access_index.hpp>
#include "charfmt.hxx"
#include "fmtcol.hxx"
#include "frmfmt.hxx"
#include "section.hxx"
#include "tox.hxx"
#include "numrule.hxx"
#include "fldbas.hxx"
class SwRangeRedline;
class SwExtraRedline;
class SwUnoCursor;
2000-09-18 16:15:01 +00:00
class SwOLENode;
class SwTable;
class SwTableLine;
class SwTableBox;
struct SwPosition;
class SwContentNode;
class SwTextNode;
2000-09-18 16:15:01 +00:00
namespace com { namespace sun { namespace star { namespace i18n {
struct ForbiddenCharacters; ///< comes from the I18N UNO interface
}}}}
2000-09-18 16:15:01 +00:00
/** provides some methods for generic operations on lists that contain SwFormat* subclasses. */
class SwFormatsBase
{
public:
virtual size_t GetFormatCount() const = 0;
virtual SwFormat* GetFormat(size_t idx) const = 0;
virtual ~SwFormatsBase() {};
};
2000-09-18 16:15:01 +00:00
template<typename Value>
class SwVectorModifyBase
{
public:
typedef typename std::vector<Value>::iterator iterator;
typedef typename std::vector<Value>::const_iterator const_iterator;
typedef typename std::vector<Value>::size_type size_type;
typedef typename std::vector<Value>::value_type value_type;
protected:
enum class DestructorPolicy {
KeepElements,
FreeElements,
};
private:
typename std::vector<Value> mvVals;
const DestructorPolicy mPolicy;
protected:
// default destructor deletes all contained elements
SwVectorModifyBase(DestructorPolicy policy = DestructorPolicy::FreeElements)
: mPolicy(policy) {}
public:
bool empty() const { return mvVals.empty(); }
Value const& front() const { return mvVals.front(); }
size_t size() const { return mvVals.size(); }
iterator begin() { return mvVals.begin(); }
const_iterator begin() const { return mvVals.begin(); }
iterator end() { return mvVals.end(); }
const_iterator end() const { return mvVals.end(); }
void clear() { mvVals.clear(); }
iterator erase(iterator aIt) { return mvVals.erase(aIt); }
iterator erase(iterator aFirst, iterator aLast) { return mvVals.erase(aFirst, aLast); }
iterator insert(iterator aIt, Value const& rVal) { return mvVals.insert(aIt, rVal); }
template<typename TInputIterator>
void insert(iterator aIt, TInputIterator aFirst, TInputIterator aLast)
{
mvVals.insert(aIt, aFirst, aLast);
}
void push_back(Value const& rVal) { mvVals.push_back(rVal); }
void reserve(size_type nSize) { mvVals.reserve(nSize); }
Value const& at(size_type nPos) const { return mvVals.at(nPos); }
Value const& operator[](size_type nPos) const { return mvVals[nPos]; }
Value& operator[](size_type nPos) { return mvVals[nPos]; }
// free any remaining child objects based on mPolicy
virtual ~SwVectorModifyBase()
{
if (mPolicy == DestructorPolicy::FreeElements)
for(const_iterator it = begin(); it != end(); ++it)
delete *it;
}
void DeleteAndDestroy(int aStartIdx, int aEndIdx)
{
if (aEndIdx < aStartIdx)
return;
for (const_iterator it = begin() + aStartIdx;
it != begin() + aEndIdx; ++it)
delete *it;
erase( begin() + aStartIdx, begin() + aEndIdx);
}
size_t GetPos(Value const& p) const
{
const_iterator const it = std::find(begin(), end(), p);
return it == end() ? SIZE_MAX : it - begin();
}
/// check that given format is still alive (i.e. contained here)
bool IsAlive(typename std::remove_pointer<Value>::type const*const p) const
{ return std::find(begin(), end(), p) != end(); }
static void dumpAsXml(struct _xmlTextWriter* /*pWriter*/) {};
};
2000-09-18 16:15:01 +00:00
template<typename Value>
class SwFormatsModifyBase : public SwVectorModifyBase<Value>, public SwFormatsBase
{
protected:
SwFormatsModifyBase(typename SwVectorModifyBase<Value>::DestructorPolicy
policy = SwVectorModifyBase<Value>::DestructorPolicy::FreeElements)
: SwVectorModifyBase<Value>(policy) {}
public:
virtual size_t GetFormatCount() const override
{ return SwVectorModifyBase<Value>::size(); }
virtual Value GetFormat(size_t idx) const override
{ return SwVectorModifyBase<Value>::operator[](idx); }
size_t GetPos(const SwFormat *p) const
{ return SwVectorModifyBase<Value>::GetPos( static_cast<Value>( const_cast<SwFormat*>( p ) ) ); }
/// check if given format is contained here
/// @precond pFormat must not have been deleted
bool ContainsFormat(SwFormat const*const pFormat) const {
Value p = dynamic_cast<Value>(const_cast<SwFormat*>(pFormat));
return p != nullptr && SwVectorModifyBase<Value>::IsAlive(p);
Avoid bad downcast of SwFrmFmt to SwSectionFmt as observed by -fsanitize=vptr e.g. during CppunitTest_writerperfect_writer: SwFmtsModifyBase<SwSectionFmt*>::Contains(SwFmt const*) const SwUndoFmtAttr::Init() SwUndoFmtAttr::SwUndoFmtAttr(SfxItemSet const&, SwFmt&, bool) SwDoc::ChgFmt(SwFmt&, SfxItemSet const&) SwDocStyleSheet::SetItemSet(SfxItemSet const&, bool) SwXStyle::SetPropertyValues_Impl(com::sun::star::uno::Sequence<rtl::OUString> const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) SwXStyle::setPropertyValues(com::sun::star::uno::Sequence<rtl::OUString> const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) SvXMLImportPropertyMapper::_FillMultiPropertySet(std::__debug::vector<XMLPropertyState, std::allocator<XMLPropertyState> > const&, com::sun::star::uno::Reference<com::sun::star::beans::XMultiPropertySet> const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySetInfo> const&, rtl::Reference<XMLPropertySetMapper> const&, _ContextID_Index_Pair*) SvXMLImportPropertyMapper::FillPropertySet(std::__debug::vector<XMLPropertyState, std::allocator<XMLPropertyState> > const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet>, _ContextID_Index_Pair*) const XMLShapeStyleContext::FillPropertySet(com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&) XMLPropStyleContext::CreateAndInsert(bool) XMLTextShapeStyleContext::CreateAndInsert(bool) SvXMLStylesContext::CopyStylesToDoc(bool, bool) SwXMLImport::InsertStyles(bool) SwXMLStylesContext_Impl::EndElement() SvXMLImport::endElement(rtl::OUString const&) ... Change-Id: Ibbf6d4def751c5a8ad1416e22b8b5255eda3dd44
2015-03-04 13:52:03 +01:00
}
};
class SwGrfFormatColls : public SwFormatsModifyBase<SwGrfFormatColl*>
{
public:
SwGrfFormatColls() : SwFormatsModifyBase( DestructorPolicy::KeepElements ) {}
};
// Like o3tl::find_partialorder_ptrequals
// We don't allow duplicated object entries!
struct type_name_key:boost::multi_index::composite_key<
SwFrameFormat*,
boost::multi_index::const_mem_fun<SwFormat,sal_uInt16,&SwFormat::Which>,
boost::multi_index::const_mem_fun<SwFormat,const OUString&,&SwFormat::GetName>,
boost::multi_index::identity<SwFrameFormat*> // the actual object pointer
>{};
typedef boost::multi_index_container<
SwFrameFormat*,
boost::multi_index::indexed_by<
boost::multi_index::random_access<>,
boost::multi_index::ordered_unique< type_name_key >
>
>
SwFrameFormatsBase;
/// Specific frame formats (frames, DrawObjects).
class SW_DLLPUBLIC SwFrameFormats : public SwFormatsBase
{
// function updating ByName index via modify
friend void SwFrameFormat::SetName( const OUString&, bool );
typedef SwFrameFormatsBase::nth_index<0>::type ByPos;
typedef SwFrameFormatsBase::nth_index<1>::type ByTypeAndName;
typedef ByPos::iterator iterator;
SwFrameFormatsBase m_Array;
ByPos &m_PosIndex;
ByTypeAndName &m_TypeAndNameIndex;
public:
typedef ByPos::const_iterator const_iterator;
typedef ByTypeAndName::const_iterator const_range_iterator;
typedef SwFrameFormatsBase::size_type size_type;
typedef SwFrameFormatsBase::value_type value_type;
SwFrameFormats();
// frees all SwFrameFormat!
virtual ~SwFrameFormats() override;
bool empty() const { return m_Array.empty(); }
size_t size() const { return m_Array.size(); }
// Only fails, if you try to insert the same object twice
std::pair<const_iterator,bool> push_back( const value_type& x );
// This will try to remove the exact object!
bool erase( const value_type& x );
void erase( size_type index );
void erase( const_iterator const& position );
// Get the iterator of the exact object (includes pointer!),
// e.g for position with std::distance.
// There is also ContainsFormat, if you don't need the position.
const_iterator find( const value_type& x ) const;
// As this array is non-unique related to type and name,
// we always get ranges for the "key" values.
std::pair<const_range_iterator,const_range_iterator>
rangeFind( sal_uInt16 type, const OUString& name ) const;
// Convenience function, which just uses type and name!
// To look for the exact object use find.
std::pair<const_range_iterator,const_range_iterator>
rangeFind( const value_type& x ) const;
// So we can actually check for end()
const_range_iterator rangeEnd() const { return m_TypeAndNameIndex.end(); }
const_iterator rangeProject( const_range_iterator const& position )
{ return m_Array.project<0>( position ); }
const value_type& operator[]( size_t index_ ) const
{ return m_PosIndex.operator[]( index_ ); }
const value_type& front() const { return m_PosIndex.front(); }
const value_type& back() const { return m_PosIndex.back(); }
const_iterator begin() const { return m_PosIndex.begin(); }
const_iterator end() const { return m_PosIndex.end(); }
void dumpAsXml(struct _xmlTextWriter* pWriter, const char* pName) const;
virtual size_t GetFormatCount() const override { return m_Array.size(); }
virtual SwFormat* GetFormat(size_t idx) const override { return operator[]( idx ); }
/// fast check if given format is contained here
/// @precond pFormat must not have been deleted
bool ContainsFormat(SwFrameFormat const& rFormat) const;
/// not so fast check that given format is still alive (i.e. contained here)
bool IsAlive(SwFrameFormat const*) const;
void DeleteAndDestroyAll( bool keepDefault = false );
bool newDefault( const value_type& x );
void newDefault( const_iterator const& position );
};
/// Unsorted, undeleting SwFrameFormat vector
class SwFrameFormatsV : public SwFormatsModifyBase<SwFrameFormat*>
{
public:
SwFrameFormatsV() : SwFormatsModifyBase( DestructorPolicy::KeepElements ) {}
};
2000-09-18 16:15:01 +00:00
class SwCharFormats : public SwFormatsModifyBase<SwCharFormat*>
{
public:
void dumpAsXml(struct _xmlTextWriter* pWriter) const;
};
class SwTextFormatColls : public SwFormatsModifyBase<SwTextFormatColl*>
{
public:
SwTextFormatColls() : SwFormatsModifyBase( DestructorPolicy::KeepElements ) {}
void dumpAsXml(struct _xmlTextWriter* pWriter) const;
};
/// Array of Undo-history.
class SW_DLLPUBLIC SwSectionFormats : public SwFormatsModifyBase<SwSectionFormat*>
{
public:
void dumpAsXml(struct _xmlTextWriter* pWriter) const;
};
2000-09-18 16:15:01 +00:00
class SwFieldTypes : public SwVectorModifyBase<SwFieldType*> {
public:
void dumpAsXml(struct _xmlTextWriter* pWriter) const;
};
2000-09-18 16:15:01 +00:00
class SwTOXTypes : public SwVectorModifyBase<SwTOXType*> {};
2000-09-18 16:15:01 +00:00
class SW_DLLPUBLIC SwNumRuleTable : public SwVectorModifyBase<SwNumRule*> {
public:
void dumpAsXml(struct _xmlTextWriter* pWriter) const;
};
2000-09-18 16:15:01 +00:00
struct CompareSwRedlineTable
{
bool operator()(SwRangeRedline* const &lhs, SwRangeRedline* const &rhs) const;
};
2000-09-18 16:15:01 +00:00
// Notification type for notifying about redlines to LOK clients
enum class RedlineNotification { Add, Remove, Modify };
typedef SwRangeRedline* SwRangeRedlinePtr;
class SwRedlineTable
2000-09-18 16:15:01 +00:00
{
public:
typedef o3tl::sorted_vector<SwRangeRedline*, CompareSwRedlineTable,
o3tl::find_partialorder_ptrequals> vector_type;
Complete the transition of SwRedlineTable::size_type ...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02 08:35:18 +01:00
typedef vector_type::size_type size_type;
static constexpr size_type npos = USHRT_MAX;
Complete the transition of SwRedlineTable::size_type ...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02 08:35:18 +01:00
//TODO: std::numeric_limits<size_type>::max()
private:
vector_type maVector;
public:
~SwRedlineTable();
bool Contains(const SwRangeRedline* p) const { return maVector.find(const_cast<SwRangeRedline*>(p)) != maVector.end(); }
Complete the transition of SwRedlineTable::size_type ...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02 08:35:18 +01:00
size_type GetPos(const SwRangeRedline* p) const;
2000-09-18 16:15:01 +00:00
bool Insert(SwRangeRedlinePtr& p);
bool Insert(SwRangeRedlinePtr& p, size_type& rInsPos);
bool InsertWithValidRanges(SwRangeRedlinePtr& p, size_type* pInsPos = nullptr);
2000-09-18 16:15:01 +00:00
Complete the transition of SwRedlineTable::size_type ...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02 08:35:18 +01:00
void Remove( size_type nPos );
void Remove( const SwRangeRedline* p );
Complete the transition of SwRedlineTable::size_type ...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02 08:35:18 +01:00
void DeleteAndDestroy( size_type nPos, size_type nLen = 1 );
void DeleteAndDestroyAll();
2000-09-18 16:15:01 +00:00
void dumpAsXml(struct _xmlTextWriter* pWriter) const;
Complete the transition of SwRedlineTable::size_type ...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02 08:35:18 +01:00
size_type FindNextOfSeqNo( size_type nSttPos ) const;
size_type FindPrevOfSeqNo( size_type nSttPos ) const;
/** Search next or previous Redline with the same Seq. No.
Search can be restricted via Lookahead.
Using 0 makes search the whole array. */
Complete the transition of SwRedlineTable::size_type ...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02 08:35:18 +01:00
size_type FindNextSeqNo( sal_uInt16 nSeqNo, size_type nSttPos ) const;
size_type FindPrevSeqNo( sal_uInt16 nSeqNo, size_type nSttPos ) const;
2000-09-18 16:15:01 +00:00
/**
Find the redline at the given position.
@param tableIndex position in SwRedlineTable to start searching at, will be updated with the index of the returned
redline (or the next redline after the given position if not found)
@param next true: redline starts at position and ends after, false: redline starts before position and ends at or after
*/
Complete the transition of SwRedlineTable::size_type ...from 9ca8a63fff65acf2ea13b391495ad232f4636548 "Use consistent integer types in the SwRedlineTable interface". This all started as an attempt to reduce the number of places a to-be-committed improved loplugin:loopvartoosmall complains about. Lets see where it ends... SwRedlineTable::size_type is now the size_type of the underlying std::vector, no longer sal_uInt16 from ancient times. I tried hard to find all places that are affected by this change, changing types of affected variables and non-static data members as needed. Some notes: * The original code used USHRT_MAX as a "not found" value. I replaced that with a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for now of value USHRT_MAX. This should eventually be changed to something more sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is best done after we have constexpr support in all toolchains, so that npos can be constexpr). It is important that the value of npos is towards positive infinity, as many places in the code use for (i = f(); // may return npos i < table.size(); ++i) table[i] ... * There are some borders where values of SwRedlineTable::size_type are converted into different types, for various reasons. But all of those other types should be large enough for practical purposes (at least 32 bits wide): MakrEntry::m_nIdx: long int SvxRedlinTable::InsertEntry: sal_uIntPtr nPos SwRangeRedline: size_t SwRedlineItr: sal_Int32 SwVbaRevision::GetPosition: sal_Int32 SwXRedlines: sal_Int32 * .uno:TrackedChangeIndex= transports textual representations of such values. libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as strings, while SwTiledRenderingTest converts them to int. * TODO: The one place I'm unsure about is SfxUInt16Items with IDs FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE in sw/source/uibase/uiview/view2.cxx. For now, I kept those as SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from those items. But I have no idea where instances of those items would actually be created, and what it would mean to change those items' types? Change-Id: Ib7a14dc67e2b970766966e43f4732abd9f045ff8 Reviewed-on: https://gerrit.libreoffice.org/34775 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-03-02 08:35:18 +01:00
const SwRangeRedline* FindAtPosition( const SwPosition& startPosition, size_type& tableIndex, bool next = true ) const;
bool empty() const { return maVector.empty(); }
size_type size() const { return maVector.size(); }
SwRangeRedline* operator[]( size_type idx ) const { return maVector[idx]; }
vector_type::const_iterator begin() const { return maVector.begin(); }
vector_type::const_iterator end() const { return maVector.end(); }
void Resort() { maVector.Resort(); }
// Notifies all LOK clients when redlines are added/modified/removed
static void LOKRedlineNotification(RedlineNotification eType, SwRangeRedline* pRedline);
2000-09-18 16:15:01 +00:00
};
/// Table that holds 'extra' redlines, such as 'table row insert/delete', 'paragraph moves' etc...
class SwExtraRedlineTable
{
private:
std::vector<SwExtraRedline*> m_aExtraRedlines;
public:
~SwExtraRedlineTable();
void Insert( SwExtraRedline* p );
void DeleteAndDestroy( sal_uInt16 nPos, sal_uInt16 nLen = 1 );
void DeleteAndDestroyAll();
void dumpAsXml(struct _xmlTextWriter* pWriter) const;
sal_uInt16 GetSize() const { return m_aExtraRedlines.size(); }
SwExtraRedline* GetRedline( sal_uInt16 uIndex ) const { return m_aExtraRedlines.operator[]( uIndex ); }
SW_DLLPUBLIC bool DeleteAllTableRedlines( SwDoc* pDoc, const SwTable& rTable, bool bSaveInUndo, sal_uInt16 nRedlineTypeToDelete );
bool DeleteTableRowRedline ( SwDoc* pDoc, const SwTableLine& rTableLine, bool bSaveInUndo, sal_uInt16 nRedlineTypeToDelete );
bool DeleteTableCellRedline( SwDoc* pDoc, const SwTableBox& rTableBox, bool bSaveInUndo, sal_uInt16 nRedlineTypeToDelete );
};
typedef std::vector<SwOLENode*> SwOLENodes;
2000-09-18 16:15:01 +00:00
#endif // INCLUDED_SW_INC_DOCARY_HXX
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */